ASP.NET Dynamic Data MVC Preview под лупой

В этом посте давайте разберёмся с тем, какая функциональность заложена в ASP.NET Dynamic Data MVC Preview. Это станет логическим продолжением того, что мы делали в предыдущем посте и станет заключительным этапом приготовления к хардкодингу.

Посмотрим на структуру проекта:

Компилируем ASP.NET Dynamic Data MVC Preview для работы с MVC 2

Давайте сегодня скачаем и разберём превью Dynamic Data для MVC. Хотя этому превью уже скоро стукнет два года, мы попробуем им воспользоваться. К сожалению, эта библиотека работает только с MVC версии 1, но у нас же есть исходный код, поэтому мы, как настоящие индейцы, попробуем подружить этот код с MVC 2.

Интересный факт о protected internal и немного о контроллерах

Вчера стало интересно как устроен внутри класс Controller из ASP.NET MVC 2.0 RC. Этот класс иллюстрирует замечательный паттерн Command, согласно которому, внутри класса должна быть реализована функция выполнения. В нашем случае,  Controller реализует интерфейс IController и определяет метод Execute, внутри которого подыскивает один из своих методов, способных обработать пришедший запрос, то есть вызывает один из своих Action-методов, которые возвращают объект подтипа абстрактного типа ActionResult.

Интересно то, что обычно эти экшены не создают новый объект, например new ViewResult(), а вызывают метод родительского класса Controller, например return View() или return Json(). Так вот, в классе Controller эти методы определены как protected internal, например,

protected internal JsonResult Json(object data)

Прочитав про модификатор internal в MSDN я узнал, что он ограничивает использование метода внутри сборки, то есть вызов метода с модификатором internal  в другой сборке приведёт к ошибке. Как же тогда оно работает? Как мы в своих контроллерах спокойно вызываем эти методы и никаких ошибок не происходит? Оказалось, что вместе модификаторы protected и internal связываются логическим или, то есть запись с ними следует читать, как
protected [OR] internal,
поэтому выходит, что вне сборки этот метод экземпляра класса вызывать нельзя, но наследникам класса в другой сборке — можно :)

Получается, что определив protected internal метод мы можем:
— внутри сборки 
          вызывать его как из классов-наследников, так и у экземпляра класса
— вне сборки
          только у наследников

Такие дела.