Гайдар Магдануров - ASP.NET MVC Framework

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

Для обмена данных между представлением и контроллером используется специальная коллекция viewData— являющаяся основным связующим звеном между контроллером и представлением .

После того как разметка была сгенерирована движком представления, веб-сервер возвращает ее в качестве ответа пользователю по протоколу HTTP. На этом жизненный цикл обработки запроса MVC-приложением заканчивается.

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

Таблица маршрутизации определяет набор правил, на основании которых происходит анализ URL-запроса и вычленения из URL информации, определяющей имя контроллера и действия контроллера, а также сопоставление параметров запроса. В проекте-заготовке правила добавляются в методе RegisterRoutes, описанном в файле Global.asax (листинг 1.1).

Листинг 1.1. Метод RegisterRoutes

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute( "Default", // Название маршрута

"{controller}/{action}/{id}", // URL с параметрами

new { controller = "Home", action = "Index", id = "" }

// Значения по умолчанию

);

}

Таблица маршрутизации заполняется двумя типами маршрутов — теми, которые должны быть обработаны MVC Framework (метода MapRouteколлекции RouteCollection), и теми, обработка которых должна быть передана дальше инфраструктуре ASP.NET в обход механизмов MVC Framework (метод IgnoreRouteколлекции RouteCollection).

В случае с игнорируемыми маршрутами задается определенный адрес либо маска. Так, приведенный в листинге 1.1 маршрут исключает запросы к файлам с расширением axd (используются инфраструктурой ASP.NET для встроенных ресурсов).

Маршруты, обрабатываемые MVC Framework, задаются набором параметров: названием маршрута для идентификации в коллекции, описанием шаблона URL и набором значений по умолчанию. Среди всех параметров обязательными являются controller— указывающий имя контроллера, обрабатывающего запросы, удовлетворяющие маске, и action— указывающий действие контроллера, обрабатывающего запрос. Все остальные параметры задаются произвольно, и их имена используются для передачи значений при вызове методов контроллера.

Рассмотрим код контроллера HomeController, приведенный в листинге 1.2.

Листинг 1.2. Код контроллера HomeController ИЗ приложения-заготовки

[HandleError]

public class HomeController : Controller {

public ActionResult Index()

{

ViewData["Message"] = "Welcome to ASP.NET MVC!";

return View();

}

public ActionResult About()

{

return View();

}

}

На примере этого кода можно рассмотреть несколько основных концепций. Прежде всего, все классы контроллеров наследуют тип Controller, предоставляющий инфраструктуру для обработки запросов.

Каждый из контроллеров содержит методы, возвращающие значения типа ActionResult. В приведенном примере используется вспомогательный метод View, возвращающий тип ViewResult, который наследует тип ActionResultи передает управление механизму представлений — если параметр "имя представления" не передан методу View, то используется имя действия в качестве имени представления.

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

В данном случае, например, действие Indexпоместит в коллекцию ViewDataэлемент Message, после чего передаст управление представлению Index.aspx, расположенному в папке /Views/Home.

Кроме того, в листинге 1.2 проиллюстрирована еще одна важная концепция, касающаяся кода контроллеров, — использование атрибутов для управления поведением контроллеров. Так, для того чтобы управлять поведением всего контроллера, можно установить атрибуты на класс контроллера, а для того чтобы управлять поведением конкретного действия — на соответствующий метод класса контроллера. В приведенном в листинге 1.2 коде используется атрибут для всего класса контроллера HandleError, который инструктирует среду MVC Framework на предмет возникновения необработанного исключения в любом из методов контроллера HomeController, необходимо будет это исключение поймать и отобразить пользователю специальную страницу с сообщением об ошибке.

В MVC Framework используется представление на основе ASPX-файлов. Так, например, рассмотрим представление Index.aspx из примера выше. Этому представлению передается коллекция viewDataс элементом Message, значение которого должно быть отображено на странице. В листинге 1.3 приведен код этого представления.

Листинг 1.3. Представление Index.aspx

ContentPlaceHolderID="TitleContent" runat="server">

Home Page

ContentPlaceHolderID="MainContent" runat="server">

To learn more about ASP.NET MVC visit

title="ASP.NET MVC Website">http://asp.net/mvc.

Как видно из листинга 1.3, в представлении используется шаблон Site.Master и метки Contentдля определения содержимого блоков ContentPlaceHolder, определенных в Site.Master.

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

Подробнее о работе с представлениями и создании сложных представлений можно узнать в главе 5.

Исходя из внутреннего устройства MVC-приложений, процесс разработки удобно построить по следующей схеме:

1. Создать модель — создать схему базы данных, по схеме базы данных создать логические структуры данных, с которыми будет работать приложение.

2. Описать физическую структуру приложения — задать маршруты, которые будут определять взаимодействие пользователя с приложением.

3. Создать контроллеры и их действия — на основании структуры приложения.