Работа с MVC проектами Visual Studio

Когда вы создаете новый MVC проект, Visual Studio дает вам возможность выбора между различными отправными точками: Empty, Basic, Internet Application, Intranet Application, Mobile Application и Web API, как показано на рисунке 12-1.

Рисунок 12-1: Выбор начальной конфигурации MVC проекта

Мы уже показали вам первые два шаблона в предыдущих главах. Шаблон проекта Empty мы использовали в главе 2 для приложения RSVP. Он содержит только необходимый минимум файлов, необходимых для MVC фреймворка.

Мы использовали шаблон проекта Basic в главе 7, когда мы создали приложение SportsStore. Его структура дополнена, по сравнению с шаблоном Empty, некоторыми макетами, файлами JavaScript и некоторыми CSS стилями, используемыми для элементов HTML форм и валидации. Шаблон Basic мы используем в наших собственных проектах, потому что скриптовые файлы и другие дополнения полезны, но мы все же можем сами реализовывать важные части проекта, как мы делали для приложения SportsStore.

Шаблоны Internet Application и Intranet Application заполнены более полно, тут используются различные механизмы аутентификации, которые подходят для интернет и интранет приложений. Шаблон Mobile Application является вариацией шаблона Internet Application, и он оптимизирован для мобильных устройств (мы объясним новые функции MVC 4 для мобильных устройств в главе 24). И, наконец, шаблон Web API создает проект, который поможет вам начать работу с новой MVC 4 Web API функцией, которую мы объясним в главе 25.

Вы можете увидеть разницу между тремя из этих шаблонов на рисунке 12-2, где мы показали содержимое Solution Explorer для шаблонов Basic, Internet Application и Intranet Application.

Рисунок 12-2: Начальное содержание, созданное шаблонами Empty, Internet Application и Intranet Application

Вы видите, что проект Internet Application является самым сложным, это потому что он реализует всю систему пользовательской аутентификации, которая требует много различных представлений. Проект Intranet Application может работать с Windows аутентификацией для обработки задач, связанных, например, со сменой пароля. А шаблон Basic по умолчанию вообще не обеспечивает аутентификацию.

В основном мы используем шаблоны Empty и Basic и рекомендуем вам делать то же самое. По умолчанию функционал в других шаблонах является слишком общим, чтобы быть полезным, и требует больших трудовых затрат. Мы получаем лучшие результаты, когда строим наши проекты с нуля.

Какой бы шаблон вы ни выбрали, вы заметите, что в результате у проектов очень похожие структуры. Некоторые из элементов MVC проекта имеют особые роли, они жестко вписаны в ASP.NET или MVC фреймворк. Другие затрагивают соглашение по именам. Мы описали каждый из этих файлов и папок в таблице 12-1.

Таблица 12-1: Элементы MVC проекта

Папка или файл	Описание	Примечание
`/App_Data`	В эту папку вы кладете закрытые данные, такие как XML-файлы или базы данных, если вы используете SQL Server Express, SQLite или другие файловые хранилища.	IIS не будет обрабатывать содержимое этой папки.
`/App_Start`	В этой папке содержатся некоторые основные параметры конфигурации для вашего проекта, в том числе определение роутов, фильтры, связки.	Мы описываем роуты в главе 13, фильтры в главе 16 и связки в главе 24.
`/bin`	Здесь размещается скомпилированная сборка для вашего MVC приложения, наряду с любыми связанными сборками, которые не в GAC.	IIS не будет обрабатывать содержимое этой директории. Вы не увидите `bin` директорию в окне Solution Explorer, пока не нажмете кнопку `Show All Files`. Поскольку это бинарные файлы, созданные при компиляции, вам обычно не следует хранить их в системе управления.
`/Content`	Здесь вы храните статический контент, как CSS стили и рисунки.	Это соглашение, но оно не обязательно. Вы можете хранить статический контент где-то еще.
`/Controllers`	Здесь хранятся классы контроллеров.	Это соглашение. Вы можете разместить классы контроллера где угодно, потому что все они скомпилированны в одну сборку.
`/Models`	Здесь вы храните классы моделей представления и доменной модели, хотя все приложения, кроме простейших, выиграют от определения доменной модели в специальном проекте, как мы продемонстрировали в `SportsStore`.	Это соглашение. Вы можете определить классы модели в любом месте проекта или в отдельном проекте.
`/Scripts`	В этой директории содержатся JavaScript библиотеки для вашего проекта. Visual Studio добавляет jQuery и некоторое другие популярные библиотеки.	Это соглашение. Вы можете поместить скриптовые файлы в любом месте, так как они в действительности являются просто еще одним типом статического контента. См. главу 24 для получения дополнительной информации об управлении скриптовыми файлами.
`/Views`	В этой директории содержатся представления и частичные представления, как правило, сгруппированные в папки с именем контроллера, с которым они связаны.	Файл `/Views/Web.config` не дает IIS обрабатывать содержимое этих директорий. Представления должны демонстрироваться через метод действия.
`/Views/Shared`	В этой директории содержатся макеты и представления, которые не являются конкретными для отдельного контроллера.
`/Views/Web.config`	Это не конфигурационный файл для вашего приложения. Он содержит настройки, необходимые для того, чтобы представления работали ASP.NET, и предотвращает то, чтобы представления не обрабатывались IIS и пространствами имен, импортированными в представления по умолчанию.
`/Global.asax`	Это глобальный класс ASP.NET приложения. Его класс с выделенным кодом (`Global.asax.cs`) является местом для регистрации настройки маршрутизации, а также настройки любого кода для запуска при инициализации приложения или завершении работы, а также при получении необработанных исключений.	Файл `Global.asax` играет такую же роль в MVC приложениях, как и в приложениях Web Forms.
`/Web.config`	Это конфигурационный файл для вашего приложения. Мы лучше поясним его роль далее в этой главе.	Файл `Web.config` играет такую же роль в MVC приложениях, как и в приложениях Web Forms.

В таблице 12-2 представлены файлы и папки, которые имеют особенное значение, если они присутствуют в MVC проекте.

Таблица 12-2: Дополнительные элементы MVC проекта

Папка или файл	Описание
`/Areas`	Области (areas) являются одним из способов разбития больших приложений на более мелкие куски. Мы расскажем об областях в главе 13.
`/App_GlobalResources`, `/App_LocalResources`	В них хранятся исходные файлы, используемые для локализации страниц Web Forms.
`/App_Browsers`	Эта папка содержит XML файлы `.browser`, которые описывают, как идентифицировать определенные веб-браузеры, и на что способны эти браузеры (например, поддерживают ли они JavaScript).
`/App_Themes`	Эта папка содержит темы Web Forms (в том числе файлы `.skin`), которые влияют на то, как отображаются элементы управления Web Forms.

Примечание
За исключением /Areas, элементы в таблице 12-2 являются частью ядра платформы ASP.NET и не особенно актуальны для MVC приложений. Адам рассказывает об основных функциях ASP.NET в своих книгах Applied ASP.NET 4.5 in Context и Pro ASP.NET 4.5, опубликованных Apress.

Понимание MVC соглашений

Есть два вида соглашений для MVC проектов. Первое из них – это действительно только предложение о том, как вы можете структурировать проект. Например, по соглашению JavaScript файлы размещаются в папке Scripts. Это место, где другие MVC разработчики в первую очередь будут их искать, а также именно сюда Visual Studio помещает исходные файлы JavaScript для нового MVC проекта. Но вы можете переименовать папку Scripts или удалить ее полностью и сохранять ваши скрипты где угодно. Это не помешает MVC фреймворку запускать приложение.

Другой вид соглашения вытекает из принципа соглашения о конфигурации, которое было одним из основных пунктов продажи, сделавшим Ruby on Rails таким популярным. Соглашение о конфигурации означает, что вам не нужно, например, явно настраивать связь между контроллерами и представлениями. Вы просто следуете определенным именованиям для ваших файлов, и все работает. Тут существует меньше гибкости в изменении структуры проекта, если вы имеете дело с таким соглашением. О соглашениях более подробно рассказывается в следующих разделах.

Совет
Все соглашения могут быть изменены, если вы используете пользовательский движок представления, который мы рассмотрим в главе 18. Но не стоит этим слишком увлекаться: по большей части вы будете использовать эти соглашения в своих MVC проектах.

Следуя соглашениям для классов контроллеров

Классы контроллеров должны иметь имена, которые заканчиваются на Controller, например, ProductController, AdminController и HomeController.

При обращении к контроллеру из другой части проекта, например, при использовании вспомогательного метода, необходимо указать первую часть имени (как Product), а MVC фреймворк автоматически добавит к имени Controller и начинает искать класс контроллера.

Совет
Вы можете изменить это поведение, если создадите свою собственную реализацию интерфейса IControllerFactory, который мы опишем в главе 17.

Следуя соглашениям для представления

Представления и частичные представления находятся в папке /Views/Controllername. Например, представление, связанное с ProductController, будет находиться в папке /Views/Product.

Совет
Обратите внимание, что мы опускаем часть класса Controller из папки Views: мы используем папку /Views/Product, а не /Views/ProductController. Это может показаться нелогичным на первый взгляд, но очень скоро вы к этому привыкнете.

MVC фреймворк ожидает, что представление по умолчанию для метода действия должно быть названо после этого метода. Например, представление по умолчанию, связанное с методом действия List следует называть List.cshtml. Таким образом ожидается, что для метода действия List в классе ProductController представление по умолчанию будет называться /Views/Product/List.cshtml.

Представление по умолчанию используется, если вы возвращаете в методе действия результат вызова метода View:

return View();

Вы можете указать другое представление по имени:

return View("MyOtherView");

Обратите внимание, что мы не включаем расширение имени файла или путь к представлению. При поиске представления MVC фреймворк смотрит в папку с именем контроллера, а затем в папку /Views/Shared. Это означает, что мы можем хранить представления, которые будут использоваться более чем одним контроллером, в папке /Views/Shared, и фреймворк их найдет.

Следуя соглашениям для макетов

Соглашение по именованиям для макетов заключается в том, что перед именем файла стоит знак подчеркивания (_), а файлы макетов помещаются в папку /Views/Shared. Visual Studio создает макет _Layout.cshtml, если используется любой шаблон, кроме Empty. Этот макет применяется ко всем представлениям по умолчанию через файл /Views/_ViewStart.cshtml.

Если вы не хотите, чтобы макет по умолчанию применялся ко всем представлениям, вы можете изменить настройки в _ViewStart.cshtml (или полностью удалить файл), чтобы указать другой макет для представления:

@{
	Layout = "~/Views/Shared/MyLayout.cshtml";
}

Или вы можете отключить любой макет для данного представления:

@{
	Layout = null;
}

12.2. Отладка MVC приложений

или RSS канал: