Файлы code-behind могут быть необходимы для представлений, использующих серверные элементы управления, требующих инициализации в различные моменты жизненного цикла страницы. Однако в подавляющем большинстве случаев такой дизайн приложений приводит к сложностям в поддержке проекта, не говоря уже о грубом нарушении подхода MVC.

Из WebForms в механизм представлений в MVC пришел и подход к повторному использованию общей разметки страниц — мастерские страницы (master pages), файлы которых имеют расширение master. Мастерские страницы представляют собой инструмент для определения общего шаблона набора страниц, определяя общую разметку для набора контентных страниц и расположение блоков, содержащихся в контентных страницах.

Принцип построения мастерской страницы следующий:

1. Задается общий дизайн страницы и блоки, общие для набора страниц.

2. В разметке мастерской страницы определяются блоки, которые будут заполнены содержимым контентных страниц с помощью разметки:

Пример мастерской страницы приведен в листинге 5.1.

3. При создании разметки контентных страниц используются блоки:

где ContentPlaceHolderIDсоответствует тому фрагменту мастерской страницы, который помечен элементом ContentPlaceHolderс соответствующим свойством id. Пример контентной страницы приведен в листинге 5.2.

Листинг 5.1. Пример мастерской страницы

" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

http://www.w3.org/1999/xhtml">

Листинг 5.2. Пример контентной страницы

о проекте

О проекте

</</code> h2>

Тут что-то написано.

Мастерские страницы могут быть вложенными, т. е. в свою очередь использовать мастерские страницы. Это может быть полезно, когда существует общая планировка всех страниц на сайте (родительская мастерская страница) и несколько вариантов планировки дизайна вложенных разделов (дочерние мастерские страницы).

На контентной странице могут быть заданы несколько блоков Content, соответствующих блокам ContentPlaceHolder, определенным на мастерской странице.

Еще одним механизмом повторного использования разметки являются пользовательские элементы управления или, в терминах MVC, частичные представления. Частичные представления — это фрагменты разметки, вынесенные в отдельный файл с расширением ascx, которые могут быть использованы на страницах представлений через вызов метода RenderPartial()класса HtmlHelper. О классе Htmlи его методах подробнее рассказано далее в этой главе. Ранее в листинге 5.1 приведен пример отображения частичного представления LogOnUserControl.ascx ().

Частичное представление содержит ту же самую разметку и строится по тем же принципам, что и представление. Пример разметки упомянутого ранее частичного представления LogOnUserControl.ascx показан в листинге 5.3. Разметка, приведенная в листинге 5.3, подробно рассматривается далее.

Листинг 5.3. Разметка частичного представления LogOnUserControl.ascx

Добро пожаловать !

[ ]

[ ]

Частичные представления могут быть использованы также при создании многократно используемых функциональных блоков на разных страницах (часто называемых гаджетами), о которых речь пойдет в конце этой главы.

В главе 1 уже рассматривалось размещение файлов в директории проекта, однако сейчас остановимся на этой теме подробнее.

Все файлы, относящиеся к представлениям, размещаются внутри директории Views, во вложенных директориях, соответствующих названиям контроллеров, использующих эти представления, либо внутри директории Shared, содержащей представления, мастерские страницы и частичные представления, используемые разными контроллерами.

Допустим, что в проекте присутствуют два контроллера: HomeControllerи AccountController, тогда структура директории Views выглядит следующим образом:

□ Account — в этой директории содержатся представления, используемые действиями контроллера Account.

□ Home — в этой директории содержатся представления, используемые действиями контроллера Home.

□ Shared — в этой директории содержатся мастерские страницы, частичные представления и представления, которые могут быть использованы всеми контроллерами, например, страница с информацией об ошибке, возникшей во время выполнения действия контроллера.

□ Из действия контроллера можно обратиться к представлению, находящемуся в любой из директорий, указав полный путь к представлению. Аналогично, представление может использовать частичные представления, размещенные в разных директориях, с указанием полного пути к ним, однако такой подход приводит к путанице, и мы настоятельно рекомендуем группировать представления, относящиеся к одному контроллеру, в одну директорию.

□ В случае, когда нескольким контроллерам может понадобиться использовать одну и ту же разметку представления, стоит подумать о будущем развитии проекта и выбрать один из двух путей.

□ Разметка всегда будет одинакова для обоих контроллеров — в этом случае представление следует разместить в директории Shared.

□ Разметка может в будущем различаться — в этом случае общую разметку следует вынести в файл частичного представления и поместить в директорию Shared, а для каждого из контроллеров создать собственное представление. Не стоит смущаться, если в начале разработки проекта каждое из представлений будет содержать только ссылку на общее частичное представление — в будущем будет значительно проще модифицировать представления для контроллеров, если избежать слияния разметки в самом начале развития проекта.

□ Директория Views предназначена только для файлов представлений, обрабатываемых механизмом генерации представлений, статические файлы, используемые на страницах (js, .css, изображения), следует размещать в других директориях. Например, в шаблонном проекте MVC Application, создаваемом Visual Studio, предлагается использовать для статических файлов директорию Content, а для скриптов .js директорию Scripts. Здесь уже выбор может определяться полностью вашим вкусом. Неплохой идеей может быть создание директории Content с вложенной структурой директорий, повторяющей структуру директории Views, где статические файлы будут размещены по тому же принципу, что и в директории Views. Возможно, что вам будет удобнее создать иную структуру директорий и группировать статические файлы не по принадлежности к представлениям, а по расположению звезд на небосклоне или какой-либо другой логике.