Гайдар Магдануров Владимир Юнев

ASP.NET MVC Framework

ГЛАВА 1

Знакомство с MVC Framework

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

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

Паттерн проектирования MVC

Аббревиатура MVC, давшая название MVC Framework, скрывает в себе всю суть архитектурного подхода построения приложений по принципу MVC: модель, представление и контроллер — это те компоненты, из которых состоит каждое приложение, созданное в этой парадигме.

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

□ Модель — компонент приложения, отвечающий за взаимодействие с источником данных (база данных, XML-файлы, файловая система и т. п.), а также содержащий описание объектов, описывающих данные, с которыми работает приложение.

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

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

Графическое представление архитектуры MVC приведено на рис. 1.1.

Важно отметить слабую связанность компонентов между собой. Компонент модель автономен и не зависит от реализации контроллеров и представлений, его реализация не зависит от реализации остальной части приложений.

С точки зрения контроллера и представления модель представляет собой черный ящик, из которого приходят или в которой помещаются определенные объекты. Говоря простым языком, модель предоставляет контроллеру и представлению некоторый контракт, в соответствии с которым все три компонента системы работают с данными в одинаковом формате.

Примечание

Преимущество такого подхода можно продемонстрировать на примере из жизни. В свое время один из авторов книги работал над Windows-приложением для ведения небольшой складской базы. Это приложение было построено на базе Windows Forms, в полной мере подход MVC не использовался, однако в приложении был выделенный автономный компонент для работы с данными — модель. В дальнейшем, когда потребовалось создать веб-приложение для доступа к складской базе данных из внутренней сети и Интернета, сборка, содержащая компонент модель, была подключена к проекту веб-приложения и использовалась совместно с работающим на сервере Windows Forms-приложением. В дальнейшем этой же моделью данных воспользовались веб-службы, которые были разработаны поверх складской базы данных.

***************************************************

Компонент представление отображает состояние объектов модели, которое модифицируется контроллером. Представлению недоступны сведения о внутренней реализации контроллера, а также работа представления не зависит от того, каким образом было модифицировано состояние объектов модели. Задача представления очень проста — отображение актуального состояния объектов модели.

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

Примечание

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

************************************************

История паттерна проектирования MVC

Подход к разработке программы с использованием разбиения на компоненты "модель", "представление" и "контроллер" был предложен в 1979 году норвежским ученым Тригве Ринскаугом, когда он работал в исследовательском центре Xerox в Пало Альто. Реализован подход был на языке Smalltalk для графических интерфейсов настольных систем. Тогда веб-приложения еще даже не маячили на горизонте, однако проблема разделения программной логики и интерфейса стояла остро — различные операционные системы предлагали разные подсистемы для отображения графического интерфейса, и при необходимости переноса приложений между платформами возможность повторного использования программной логики при изменении только кода, работающего с графической подсистемой, оказалась весьма кстати.

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

Примечание

Даже быстрый поиск позволяет получить большое количество результатов: Maverick.NET, Monorail, ProMesh.NET, PureMVC, Mach-II, Model-Glue, FuseBox, Aranea, Cocoon, Grails, GWT, Spring, Struts, Stripes, Tapestry, WebObjects, Wicket, JSF, SproutCore, Wawemaker, Dojo, Catalyst, CGI:Application, Solstice, Gantry, CakePHP, Joomla, Odin Assemble, Prado, Solar, Zand Framework, Symfony, Django, Pylons, Enthought, Zope, web2py, Camping, Merb, Nitro, Ramaze, Ruby on Rails, XForms.

******************************

В ноябре 2002 года паттерн MVC был выбран для поддержки в новом стандарте веб-форм XForms, входящем в спецификацию XHTML 2.0, на момент написания этой книги все еще находящейся в статусе черновика.

В декабре 2007 года на суд публике была представлена первая предварительная версия ASP.NET MVC Framework, финальная версия 1.0 которого была выпущена в марте 2009 года.

Преимущества подхода разработки MVC

Использование MVC Framework для веб-приложений на базе ASP.NET приносит ряд преимуществ при разработке и поддержке решений. Выделим три основные преимущества, с которыми разработчик сталкивается, едва приступив к разработке.

1. Полный контроль над кодом разметки

При использовании подходов к разработке веб-приложений, предполагающих автоматическую генерацию кода разметки, таких как WebForms для ASP.NET, разработчик теряет контроль над финальной разметкой, которую получает браузер пользователя. В результате полученные страницы могут не удовлетворять требованиям конечного пользователя — некорректно отображаться в некоторых браузерах или содержать избыточный код разметки.

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

2. Расширяемость

Компоненты MVC Framework разработаны таким образом, чтобы обеспечивать максимальную расширяемость самой библиотеки. Имеется возможность использования разных библиотек для обработки представлений, собственных алгоритмов создания объектов контроллеров, а также расширение внутренних механизмов функционирования компонентов библиотеки.

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

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

3. Простота автоматического тестирования

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

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

Установка MVC Framework

Для того чтобы разрабатывать приложения с использованием MVC Framework, необходимо установить следующие доступные бесплатно для скачивания компоненты:

□ среда разработки Visual Web Developer 2008 Express Edition http://www.microsoft.com/express/download/ (русская версия http:// www.microsoft.com/rus/express/, приложена на диске);

□ сервер баз данных SQL Server 2008 Express Edition http://www.microsoft.com/express/sql/download/ (русская версия http://www.microsoft.com/rus/express/sql/download/, приложена на диске);

□ библиотека Microsoft ASP.NET MVC http://www.asp.net/mvc/download/.

Установка этих компонентов не должна вызвать сложностей — достаточно запустить мастер установки каждого из компонентов в указанном порядке и следовать инструкциям на экране.

MVC Framework работает c Visual Web Developer Express и со всеми старшими редакциями Visual Studio, если для них установлен компонент Visual Web Developer, поэтому вы можете использовать более старшую редакцию, если она вам доступна. Аналогично можно использовать любую редакцию SQL Server.

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

Первое приложение на MVC Framework

После установки MVC Framework в списке доступных проектов в Visual Studio появится пункт ASP.NET MVC Web Application. Этот тип проекта доступен только в случае, если выбрана версия .NET Framework 3.5 (рис. 1.2).

Во время создания проекта, который мы в дальнейшем будем называть MVC-приложением, Visual Studio предложит сразу же создать оснастку для тестирования веб-приложения (рис. 1.3). Мы не будем затрагивать тему тестирования MVC-приложений до соответствующей главы, поэтому при создании первого приложения откажемся от создания проекта тестирования.

Visual Studio создаст заготовку проекта MVC-приложения (рис. 1.4), которой мы воспользуемся для изучения составляющих компонентов MVC-приложений.

Проект MVC-приложения представляет собой типовой проект ASP.NET Web Application (Веб-приложение ASP.NET). Напомним, что в отличие от проекта веб-сайта ASP.NET (ASP.NET Web Site), когда проект описывается хранящимися в директории проекта файлами, веб-приложение содержит еще и файл с описанием проекта, в котором описаны основные настройки компиляции и отладки проекта, а также указаны пути к файлам, включенным в проект.

Особенно следует отметить, что MVC-приложения используют стандартную инфраструктуру ASP.NET и, фактически, являются обычными ASP.NET-приложениями, к которым подключены компоненты HttpHandler, меняющие

Рис. 1.4. Заготовка MVC-приложения, созданного Visual Studio

логику обработки запросов с целью использования парадигмы MVC. В то же время, в приложении используются файлы Web.config для хранения конфигурации всего веб-приложения и Global.asax для создания глобальных обработчиков событий уровня всего приложения, точно так же, как и в классических ASP.NET-приложениях, использующих компоненты WebForms.

Структура MVC-приложения

Рассмотрим то, как представлены основные компоненты MVC-приложения в виде физических файлов на примере созданного Visual Studio проекта-заготовки.

В структуре папок MVC-приложения важны только две папки: Controlles, в которой размещается код контроллеров, и Views, в которой размещается код представлений. Все остальные папки могут быть произвольно переименованы или удалены из проекта.

Папка Content

В папке Content предлагается размещать файлы, используемые для создания интерфейса приложения на стороне клиента и загружаемые с сервера без изменений. В проекте-заготовке в папке Content размещен файл Site.css, представляющий собой каскадную таблицу стилей для страниц проекта.

Папка Controllers

В папке Controllers размещаются файлы с логикой контроллеров (в нашем случае, поскольку был выбран язык C#, файлы имеют расширение cs). Каждый файл отвечает классу контроллера.

Применяется следующее именование классов контроллеров, которое в свою очередь используется для именования файлов: имяКонтроллераСоntroller.

В проекте-заготовке созданы два файла контроллера: HomeController, отвечающий за логику страничек сайта, и Accountcontroller, отвечающий за логику регистрации и авторизации пользователей.

Чуть далее в этой главе описана внутренняя структура классов контроллеров.

Папка Models

В папке Models предлагается размещать файлы с логикой взаимодействия с базой данных (модель в паттерне MVC). В приложении-заготовке не генерируется код для работы с данными, поскольку это приложение очень простое и лишь предоставляет базовую структуру. В связи с этим созданная Visual Studio папка Models пуста.

Папка Scripts

В папке Scripts предлагается размещать файлы с кодом клиентских скриптов, используемых на клиенте. В проекте-заготовке уже включены библиотеки JavaScript-кода: MicrosoftAjax — содержащая код для создания клиентской инфраструктуры Microsoft Ajax, MicrosoftAjaxMvc — содержащая код, работающий поверх инфраструктуры Microsoft Ajax и используемый MVC Framework для реализации поддержки асинхронного обновления форм, а также jQuery — популярная библиотека, предоставляющая методы для манипуляции с объектами HTML-документов.

Подробнее об использовании возможностей клиентских библиотек можно узнать в главе, посвященной клиентскому программированию с использованием MVC Framework.

Папка Views

В папке Views размещаются файлы представления. В качестве стандартного механизма представлений в MVC Framework используются ASPX-файлы для создания представлений, MASTER-файлы для создания шаблонов общей разметки части представлений, а также ASCX-файлы для создания частичных представлений для многократного использования в составе других представлений.

Если вы знакомы с WebForms в ASP.NET, то представления по сути являются страницами ASP.NET без использования серверных элементов управления и серверных форм.

В папке Views файлы представлений размещаются следующим образом: для каждого контроллера в папке Views создается вложенная папка по имени этого контроллера (для HomeController папка Home, для AccountController папка Account). Помимо этого используется вложенная папка Shared для представлений, шаблонов и частичных представлений, используемых несколькими представлениями (структура для приложения-заготовки показана на рис. 1.5).

Рис. 1.5. Структура папок представлений для приложения-заготовки

При создании проекта-заготовки в папку Views помещается файл Web.config, описывающий конфигурацию этой папки. В этом файле для папки назначен специальный обработчик, запрещающий доступ к файлам в этой папке пользователям на уровне веб-сервера.

<handlers>

<remove name="BlockViewHandler"/>

<add name="BlockViewHandler"

path="*" verb="*" preCondition="integratedMode"

type="System.Web.HttpNotFoundHandler"/>

</handlers>

Соотнесение представлений и методов контроллеров описано далее в этой главе.

Файл Default.aspx

Файл Default.aspx создается в качестве заглушки, для того чтобы веб-сервер вызывал инфраструктуру ASP.NET при обращении к сайту без указания пути (например, http://www.remix.ru/). Сама по себе страница Defaut.aspx пуста и содержит в обработчике события загрузки страницы код, который переадресует вызов инфраструктуре ASP.NET.

public void Page_Load(object sender, System.EventArgs e)

{

string originalPath = Request.Path;

HttpContext.Current.RewritePath(Request.ApplicationPath, false);

IHttpHandler httpHandler = new MvcHttpHandler();

httpHandler.ProcessRequest(HttpContext.Current);

HttpContext.Current.RewritePath(originalPath, false);

}

Файл Global.asax

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

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

}

Метод RegisterRoutes описан подробнее далее в этой главе.

Файл Web.config

Файл Web.config описывает конфигурацию приложения, именно в конфигурации описаны модули и обработчики, которые позволяют работать MVC Framework.

Основным модулем является модуль маршрутизации, который вызывается для всех запросов и инициирует работу инфраструктуры MVC Framework.

<add name="UrlRoutingModule"

type="System.Web.Routing.UrlRoutingModule, System.Web.Routing,

Version=3.5.0.0,

Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

Рассмотрев физическую структуру файлов MVC-приложения, перейдем к принципам функционирования и внутреннего устройства компонентов MVC-приложения.

Обработка запросов MVC-приложением

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

Поступающий к веб-серверу HTTP-запрос передается среде выполнения ASP.NET, которая инициализирует инфраструктуру MVC Framewrok и передает запрос для обработки компоненту маршрутизации. На основании таблицы маршрутизации, загружаемой при запуске веб-приложения, модуль маршрутизации определяет имена контроллера и метода контроллера, который должен обработать запрос, а также параметры запроса, которые должны быть переданы контроллеру. После этого генерируется контекст запроса, содержащий параметры запроса и среды выполнения приложения (такие как URL запроса, IP-адрес клиента и сервера и т. п.), создается экземпляр класса контроллера и ему передается управление путем вызова соответствующего метода класса контроллера — действия контроллера в терминах MVC.

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

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

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

Компоненты 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

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="indexTitle"

ContentPlaceHolderID="TitleContent" runat="server">

Home Page

</asp:Content>

<asp:Content ID="indexContent"

ContentPlaceHolderID="MainContent" runat="server">

<h2><%= Html.Encode(ViewData["Message"]) %></h2>

<p>To learn more about ASP.NET MVC visit

<a href="http://asp.net/mvc"

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

</p>

</asp:Content>

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

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

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

Подход к разработке MVC-приложений

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

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

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

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

4. Создать представления — для каждого из действий контроллеров создать представления, учитывая возможность вынесения повторяющихся элементов в частичные представления и шаблоны.

5. Разработать модульные тесты для тестирования логики представления, если планируется модификация логики в процессе поддержки и развития приложения.

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

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

Заключение

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

ГЛАВА 2

MVC Framework и WebForms

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

Известный факт, что возможность выбора порождает проблему этого самого выбора — поэтому с появлением на платформе ASP.NET подхода к созданию веб-приложений MVC Framework у разработчиков возникает логичный вопрос — какой подход выбрать и какой подход будет наиболее оправдан при создании очередного веб-приложения. Не хотелось бы расстраивать читателя, жаждущего быстрого ответа на вопрос, какой подход избрать — WebForms или MVC Framework, но все же придется это сделать — ответом на вопрос, стоит ли выбрать MVC Framework для вашего следующего веб-приложения, является вся эта книга.

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

В этой главе проводится краткое сравнение технологий MVC Framework и WebForms, демонстрируется реализация подхода MVC на основе WebForms, что может быть полезно разработчикам, знакомым с WebForms, для того чтобы быстро освоиться с концепцией MVC, а также предлагаются некоторые советы по выбору той или иной технологии.

Сравнение WebForms и MVC Framework

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

Технология WebForms

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

Технология WebForms значительно снизила "порог входа" в веб-разработку. Как в свое время появление визуальных средств разработки вроде Visual Basic дало возможность разработчикам разного уровня создавать приложения различной сложности, так появление технологии WebForms привело к быстрому росту количества динамических веб-приложений. Прежде всего, за счет возможности быстрого изучения технологии и быстрого старта разработки полнофункциональных приложений.

Модель расширения WebForms позволила большому количеству компаний разрабатывать собственные элементы управления, которые позволили существенно упростить и ускорить разработку веб-приложений. Кроме того, декларативный подход технологии WebForms позволяет очень просто преобразовывать классические веб-приложения для использования новейших технологий, таких как Ajax и Silverlight.

Преимущества WebForms

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

□ Большое количество готовых компонентов. В состав .NET Framework входит несколько десятков компонентов для реализации наиболее частых сценариев, а готовые компоненты третьих компаний позволяют сократить время на разработке и отладке собственных решений.

□ Богатая поддержка средствами разработки. Поддержка WebForms визуальными инструментами разработки, такими как Visual Studio и Expression Web, предоставляет возможность визуального проектирования интерфейса и создания базовых связей между элементами управления. Значительная часть разработки интерфейса приложения может быть выполнена веб-дизайнером, без привлечения разработчика.

□ Автоматическое управление состоянием. Состояние элементов управления на стороне клиента поддерживается автоматически, и разработчику нет необходимости отслеживать инициализацию всех элементов управления страниц между отправками данных на сервер (postback).

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

□ Высокая степень абстракции над HTML-разметкой. Разработчику нет необходимости работать со страницей на уровне HTML-разметки. Элементы управления создают необходимую разметку во время генерации разметки для конечного пользователя. Кроме того, абстракция над разметкой позволяет генерировать разметку в зависимости от браузера, используемого для доступа к веб-приложению, что особенно важно для приложений, используемых на мобильных устройствах.

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

□ Возраст технологии. В современном быстро меняющемся мире десяток лет — это уже очень много. За время существования WebForms было выработано множество методик создания веб-приложений, продуманы различные сценарии использования технологии и накоплен большой опыт в сообществах разработчиков.

Недостатки WebForms

□ Связка разметки и логики страницы. Разметка страницы, определенная в ASPX-файле, жестко привязана к коду логики, определенному в codebehind-файле, поскольку на основании разметки генерируется частичный класс, являющийся частью класса, определенного в code-behind-файле. В терминах MVC получается, что логика компонентов контроллера и представления смешиваются. Особенно в случае использования элементов, декларативно работающих с данными, таких как SqlDataSource/DataGrid, смешивается бизнес-логика, логика интерфейса и работы с данными.

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

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

□ Неестественная для веб-среды модель сохранения состояния. Модель событий и хранения состояния, являющаяся преимуществом WebForms и позволяющая создавать веб-приложения по образу и подобию настольных приложений, является и недостатком этой модели. HTTP-протокол не поддерживает состояния и, при попытке это состояние добавить в жизненный цикл приложения, приходится создавать нагромождения дополнительного слоя логики, отвечающего за работу с состоянием. При использовании большого количества элементов на странице скрытое поле ViewState, используемое для хранения состояния между отправками данных формы на сервер, может достигать больших размеров, существенно влияя на скорость передачи данных между сервером и клиентом. В этом случае разработчику приходится приложить дополнительные усилия по оптимизации хранимых данных о состоянии, использовать другие механизмы для хранения состояния и так или иначе вмешиваться в стандартную модель WebForms.

Технология MVC Framework

В главе 1 были перечислены некоторые преимущества архитектурного подхода MVC и реализации в MVC Framework. Здесь же мы подробнее остановимся на достоинствах и недостатках MVC Framework в сравнении с WebForms.

Преимущества MVC Framework

□ Четкое разделение логических слоев. Отделение представления от контроллера предоставляет возможность простой замены движка представления без модификации кода контроллера, независимость от реализации модели позволяет описать только интерфейсы объектов и подменять реализацию при необходимости.

□ Полный контроль над разметкой. Возможность получить "чистый" HTML-код значительно упрощает разработку и поддержку клиентского JavaScript-кода.

□ Логическое разделение функциональности. В веб-приложениях MVC есть четкое разделение на действия контроллеров, и каждое действие имеет собственный URI. В случае WebForms страница может инкапсулировать различную логику работы страницы и сохранять тот же самый URI, например Default.aspx, при выполнении операций со страницей. В MVC-приложении разные действия, инициируемые страницей, соответствуют различным действиям контроллера. Так, например, метод Edit контроллера возвращает страницу, а метод Update используется для обновления данных и отображения сообщения об изменении данных.

□ "Красивые" URL-адреса. Поскольку MVC Framework предполагает использование гибкой системы маршрутизации, пользователь получает удобные и понятные URL-адреса страниц в виде /Products/List, /Products/Edit/1 и т. п.

□ Прозрачный процесс обработки запроса. Жизненный цикл страницы в WebForms описывается механизмом событий, этот механизм легко расширяется и позволяет добавлять расширенную функциональность в страницу без модификации кода самой страницы — через глобальные обработчики HttpModule на события той или иной страницы может быть подписан внешний обработчик. Однако в больших и сложных системах наличие множества обработчиков страницы делает процесс обработки запроса нелинейным и сложным для отладки. Кроме того, для успешной работы со страницами в WebForms разработчику нужно очень хорошо представлять последовательность выполнения действий по инициализации инфраструктуры страницы, для того чтобы вносить необходимые модификации в общее течение процесса обработки страницы. В случае MVC Framework процесс обработки запроса легко прослеживается, поскольку обработка запроса разделена на небольшое количество очень простых шагов.

□ Поддержка различных движков генерации разметки. Компоненты представления, входящие в поставку MVC Framework, могут быть легко заменены на написанные самостоятельно либо разработанные другими разработчиками. В проекте MVCContrib (http://www.codeplex.com/MVCContrib) доступны альтернативные движки представления, такие как Brail, NHaml, NVelocity и XSLT.

□ Полноценная поддержка всех возможностей платформы ASP.NET. Применяя MVC Framework, разработчик может использовать все возможности платформы ASP.NET точно так же, как и разработчик, использующий WebForms. MVC Framework не ограничивает использование стандартных служб ASP.NET, таких как Session, Cache, Membership, Profile, Roles и т. п.

Недостатки MVC Framework

□ Более высокий "порог входа" в технологию. Разработчику, только начинающему осваивать создание веб-сайтов, потребуется достаточно подробное изучение веб-технологий, таких как HTML, CSS и JavaScript, для успешного создания многофункциональных веб-приложений. Если технология WebForms во многом "экранирует" разработчика от веб-среды, предоставляя высокую степень абстракции над веб-страницами, то MVC Framework сразу же требует достаточно глубокого понимания веб-технологий.

□ Отсутствие механизма хранения состояния. MVC Framework не предлагает механизма хранения состояния, и разработчику необходимо реализовывать его самостоятельно, используя скрытые поля, cookie-файлы или хранение данных в URL.

□ Сложности создания библиотек компонентов. Отсутствие механизма элементов управления, присутствующего в WebFroms, затрудняет создание компонентов для повторного использования. При существующем подходе к созданию представлений инкапсуляция полной логики повторно используемого компонента в отдельную сборку затруднена.

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

Выбор подхода к разработке веб-приложения

На платформе ASP.NET можно создать любое веб-приложение, с любым уровнем сложности и возможностями по масштабированию, несмотря на выбранный подход, однако правильный выбор подхода позволит достичь результата меньшими усилиями и упростить дальнейшую поддержку проекта. Приступая к проектированию очередного веб-приложения, вы, возможно, задумаетесь о выборе подхода WebForms или MVC Framework.

Как уже было сказано ранее, такой выбор можете сделать только вы, основываясь на своих знаниях технологии WebForms и MVC Framework, исходя из требований того самого приложения, над которым вы размышляете. Тем не менее постараемся сформулировать список требований, который может пригодиться при выборе между WebForms и MVC Framework. Требования с краткими комментариями приведены в табл. 2.1. Большинство приведенных требований весьма условны и предназначены лишь для того, чтобы дать читателю пищу для размышлений.

Рассмотрев приведенные в табл. 2.1 требования, можно грубо определить, насколько MVC Framework может быть использована для решения конкретной поставленной задачи.

Нужно отметить еще один важный принцип, который может быть полезен при выборе технологии: предыдущий опыт разработки участников команды, которая будет работать над новым проектом. В случае если у членов команды был опыт создания приложений с использованием платформы PHP, Ruby, Perl и т. п., то очевидным выбором будет MVC Framework, однако если члены команды имеют большой опыт разработки с использованием WebForms или JSP, то переход на MVC Framework может быть для них достаточно длительным, поскольку работа с технологиями вроде WebForms вырабатывает определенный стиль кодирования, и для упрощения разработки и поддержки могут быть использованы различные архитектурные подходы (например, такие как Web Client Software Factory от команды Patters & Practices в Microsoft). MVC Framework навязывает общую архитектуру и подход к написанию кода веб-приложения, а привычки достаточно сложно изменить. Поэтому, если сроки сдачи проекта небольшие, а в команде в основном программисты, знакомые с WebForms, данный аргумент может пересилить все остальные, приведенные ранее.

Реализация подхода MVC в WebForms

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

Рассмотрим ASPX-страницу, приведенную в листинге 2.1. На этой странице размещены несколько элементов управления Label, TextBox и Button. Логика страницы должна быть простой, и в классической модели WebForms описывается в code-behind-файле, код которого приведен в листинге 2.2.

Листинг 2.1. Страница Default.aspx

<%@ Page Language="C#" AutoEventWireup="true"

CodeBehind="Default.aspx.cs" Inherits="WebFormsMvc._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

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

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title></title>

</head>

<body>

<form id="form1" runat="server">

<div>

<div>

Ответ сервера:

<asp:Label ID="lblResponse" runat="server"

Text="noKa HeT"></asp:Label>

</div>

<table>

<tr>

<td>

Имя:

</td>

<td>

<asp:TextBox ID="txtFirstName"

runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td>

Фамилия:

</td>

<td>

<asp:TextBox ID="txtLastName"

runat="server"></asp:TextBox>

</td>

</tr>

<tr>

<td colspan="2">

<asp:Button ID="btnSave" runat="server"

Text="Coxpaнить" onclick="btnSave_Click" />

</td>

</tr>

</table>

</div>

</form>

</body>

</html>

Листинг 2.2. Файл Default.aspx.cs

using System;

using WebFormsMvc.Controllers;

namespace WebFormsMvc {

{

protected void btnSave_Click(object sender, EventArgs e) {

lblResponse.Text = txtFirstName.Text + " "

+ txtLastName.Text; }

}

}

Для того чтобы выделить отдельный компонент контроллер, который будет отвечать за логику обработки запросов к странице, таких, например, как щелчок по кнопке или загрузка первоначальных значений в текстовые поля, необходимо обеспечить возможность контроллера модифицировать модель, отображением которой является представление. В случае ASPX-страницы моделью является собственно сама объектная модель страницы, поэтому именно к ней нужно предоставить доступ контроллеру — для этого достаточно отредактировать CS-файл, автоматически создаваемый Visual Studio для страницы, и сделать все поля, соответствующие элементам управления на форме, публичными, как это приведено в листинге 2.3.

Листинг 2.3. Модифицированный файл Default.aspx.designer.cs

namespace WebFormsMvc {

public partial class _Default {

public global::System.Web.UI.HtmlControls.HtmlForm form1;

public global::System.Web.UI.WebControls.Label lblResponse;

public global::System.Web.UI.WebControls.TextBox txtFirstName;

public global::System.Web.UI.WebControls.TextBox txtLastName;

public global::System.Web.UI.WebControls.Button btnSave;

}

}

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

Листинг 2.4. Файл DefaultPageControNer.cs

namespace WebFormsMvc.Controllers {

public class DefaultPageController {

public DefaultPageController(_Default pg) { page = pg; }

public void ButtonSaveClick()

{

page.lblResponse.Text = page.txtFirstName.Text + " "

+ page.txtLastName.Text;

}

public void PageLoad()

{

if (!page.IsPostBack)

{

page.txtFirstName.Text = "Иван";

page.txtLastName.Text = "Кузнецов";

}

}

}

}

Листинг 2.5. Модифицированный файл Default.aspx.cs

using System;

using WebFormsMvc.Controllers;

namespace WebFormsMvc {

public partial class _Default:System.Web.UI.Page {

protected DefaultPageController controller;

protected void btnSave_Click(object sender, EventArgs e)

{

controller.ButtonSaveClick();

}

protected void Page_Load(object sender, EventArgs e)

{

controller = new DefaultPageController(this);

controller.PageLoad();

}

}

Теперь, когда логика страницы вынесена в отдельную сущность — контроллер, есть возможность тестирования логики в отрыве от представления. Для этого достаточно создать экземпляр класса контроллера и передать ему проинициализированный объект модели. Поскольку в качестве модели выступает ASPX-страница, необходимо создать экземпляр класса страницы и про-инициализировать значащие элементы управления, поскольку при тестировании не будут задействованы внутренние механизмы создания экземпляров страниц.

В листинге 2.6 приведен простейший unit-тест для проверки обработчика события загрузки страницы.

Листинг 2.6. Unit-тест для события загрузки страницы

[TestMethod]

public void TestPageLoad()

_Default page = new _Default();

page.txtFirstName = new TextBox();

page.txtLastName = new TextBox();

DefaultPageController controller = new DefaultPageController(page);

controller.PageLoad();

Assert.AreEqual(page.txtLastName.Text, "Кузнецов");

}

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

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

Совмещение WebForms и MVC Framework в рамках одного веб-приложения

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

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

Использование элементов управления WebForms в MVC-приложениях

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

Чтобы продемонстрировать эту возможность, используем декларативный источник данных sqlDataSource и GridView в представлении Index.aspx, в результате получим страницу, приведенную на рис. 2.1. Код страницы приведен в листинге 2.7.

Листинг 2.7. Страница Index.aspx

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent"

runat="server">

Home Page

</asp:Content>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent"

runat="server">

<h2>

<%= Html.Encode(ViewData["Message"]) %>

</h2>

<form runat="server">

<asp:SqlDataSource ID="SqlDataSource1" runat="server"

ConnectionString="<%$ ConnectionStrings:ConnectionString %>"

SelectCommand="SELECT * FROM [Persons]">

</asp:SqlDataSource> <br />

<asp:GridView ID="GridView1" runat="server"

AutoGenerateColumns="False"

DataKeyNames="PersonId" DataSourceID="SqlDataSource1">

<Columns>

<asp:BoundField DataField="PersonId"

HeaderText="PersonId" InsertVisible="False"

ReadOnly="True" SortExpression="PersonId" />

<asp:BoundField DataField="LastName"

HeaderText="LastName" SortExpression="LastName" />

<asp:BoundField DataField="FirstName"

HeaderText="FirstName" SortExpression="FirstName" />

</Columns>

</asp:GridView>

</form>

</asp:Content>

Результат обращения к действию Index контроллера Home представлен на рис. 2.2. Если, к примеру, включить возможность сортировки в GridView, после чего щелкнуть по ссылке в заголовке таблицы, то будет отображена ошибка, представленная на рис. 2.3, поскольку MVC Framework не позволяет корректно обработать серверные события.

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

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

Внедрение страниц WebForms в MVC-приложения

Чтобы использовать страницу WebForms в MVC-приложении, нет необходимости писать большое количество кода. Поскольку MVC-приложение по сути является ASP.NET-приложением, и при его создании нет препятствий к использованию WebForms, все, что нужно сделать — объяснить системе маршрутизации MVC Framework, что для страниц WebForms эту самую систему маршрутизации использовать не надо. Для этого достаточно добавить в файле Global.asax в метод RegisterRoutes правило для игнорирования путей к страницам ASPX:

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

После этого в MVC-приложение можно добавить стандартную ASPX-страницу, например WebForm1.aspx, код которой приведен в листинге 2.8, и для этой страницы будет обеспечена полноценная функциональность WebForms, что подтверждает рис. 2.4.

Листинг 2.8. Страница WebForml.aspx

<%@ Page Language="C#" AutoEventWireup="true"

CodeBehind="WebForm1.aspx.cs"

Inherits="MvcWebFormsCompositeApp.WebForm1" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

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

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title></title>

</head>

<body>

<form runat="server">

<asp:SqlDataSource ID="SqlDataSource1" runat="server"

ConnectionString="<%$ ConnectionStrings:ConnectionString %>"

SelectCommand="SELECT * FROM [Persons]">

</asp:SqlDataSource>

<br/>

<asp:GridView ID="GridView1" runat="server"

AutoGenerateColumns="False" DataKeyNames="PersonId"

DataSourceID="SqlDataSource1">

<Columns>

<asp:BoundField DataField="PersonId"

HeaderText="PersonId"

InsertVisible="False" ReadOnly="True"

SortExpression="PersonId" />

<asp:BoundField DataField="LastName"

HeaderText="LastName" SortExpression="LastName" />

<asp:BoundField DataField="FirstName"

HeaderText="FirstName" SortExpression="FirstName" />

</Columns>

</asp:GridView>

</form>

</body>

</html>

Использование MVC Framework в существующих решениях WebForms

Рассмотрим сценарий расширения существующего WebForms-приложения с использованием MVC Framework. Для этого нужно выполнить несколько простых шагов:

1. Установить в свойствах веб-приложения версию .NET Framework 3.5, поскольку если приложение WebForms было разработано для версии .NET Framework 2.0, то MVC Framework для нее не поддерживается.

2. Добавить ссылки на сборки System.Web.Mvc и System.Web.Routing.

3. Зарегистрировать в файле web.config необходимые для функционирования MVC-приложения обработчики в разделе system.web/httpModules (листинг 2.9) и system/webServer/modules и system/webServer/handlers (листинг 2.10). Необходимые изменения выделены полужирным. Кроме того, поскольку в листингах 2.9 и 2.10 сборки указываются без описания версий, необходимо в директорию bin веб-приложения скопировать файлы System.Web.Mvc.dll и System.Web.Routing.dll. Либо указать полные имена сборок, посмотрев описания в тестовом MVC-приложении, которое стоит создать по такому случаю.

4. Зарегистрировать пространства имен, которые будут использовать представления (листинг 2.11).

5. Создать таблицу маршрутизации в файле global.asax (листинг 2.12).

6. Создать директорию /Controllers, разместить в ней контроллеры.

7. Создать директорию /Views и разместить в ней дерево представлений, отвечающее контроллерам и их действиям (рис. 2.5).

Листинг 2.9. Регистрация модуля MVC Framework в web.config

<system.web>

<httpModules>

<add name="UrlRoutingModule"

type=" System.Web.Routing.UrlRoutingModule,

System.Web.Routing" />

<add name="ScriptModule"

type="System.Web.Handlers.ScriptModule,

System.Web.Extensions"/>

</httpModules>

Листинг 2.10. Регистрация модулей и обработчиков MVC Framework в web.config

<system.webServer>

<validation validateIntegratedModeConfiguration="false"/>

<modules runAllManagedModulesForAllRequests="true">

<add name="ScriptModule" preCondition="managedHandler"

type="System.Web.Handlers.ScriptModule,

System.Web.Extensions"/>

<add name="UrlRoutingModule" type="

System.Web. Routing.UrlRoutingModule,

System.Web.Routing" />

</modules>

<handlers>

<add name="ScriptHandlerFactory" verb="*"

path="*.asmx" preCondition="integratedMode"

type="System.Web.Script.Services.ScriptHandlerFactory,

System.Web.Extensions"/>

<add name="ScriptHandlerFactoryAppServices" verb="*"

path="*_AppService.axd" preCondition="integratedMode"

type="System.Web.Script.Services.ScriptHandlerFactory,

System.Web.Extensions"/>

<add name="ScriptResource" preCondition="integratedMode"

verb="GET,HEAD" path="ScriptResource.axd"

type="System.Web.Handlers.ScriptResourceHandler,

System.Web.Extensions" />

<add name="MvcHttpHandler" preCondition="integratedMode" verb="*"

path=" *.mvc" type=" System.Web.Mvc.MvcHttpHandler,

System.Web.Mvc"/>

<add name="UrlRoutingHandler" preCondition="integratedMode"

verb="*" path="UrlRouting.axd"

type="System.Web.HttpForbiddenHandler, System.Web" />

</handlers>

</system.webServer>

Листинг 2.11. Регистрация пространств имен в файле web.config

<pages>

<namespaces>

<add namespace="System.Web.Mvc"/>

<add namespace="System.Web.Mvc.Ajax"/>

<add namespace="System.Web.Mvc.Html"/>

<add namespace="System.Web.Routing"/>

<add namespace="System.Iiinq"/>

<add namespace="System.Collections.Generic"/>

</namespaces>

Листинг 2.12. Таблица маршрутизации в файле Global.asax

public static void RegisterRoutes(RouteCollection routes)

{

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

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

routes.MapRoute("Default", "{controller}/{action}/{id}",

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

}

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

}

Рис. 2.5. Структура WebForms-приложения после добавления MVC-компонентов

После того как все необходимые шаги выполнены, можно продолжать пользоваться WebForms-приложением, а также использовать только что добавленные контроллер и представление, например, создав контроллер Home (листинг 2.13) и представление Index (листинг 2.14), можно получить при обращении по пути /Home/Index результат, представленный на рис. 2.6.

Листинг 2.13. Файл HomeController.cs

using System.Web.Mvc;

namespace WebFormsMvcInterop.Controllers {

public class HomeController : Controller {

public ActionResult Index()

{

return View();

}

}

}

Листинг 2.14. Файл Index.aspx

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//

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

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<h1>Hello from MVC</h1>

</body>

</html>

Заключение

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

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

ГЛАВА 3

Модель и доступ к данным

Согласно паттерну проектирования MVC основное назначение модели — это определение объекта приложения, представлением которого является вид (View). Модель и вид отделены друг от друга и взаимодействуют только в виде оповещений: изменившись, модель оповещает вид, который, согласно новым данным, изменяет свое состояние. Со своей стороны, вид обращается к модели для получения актуальных данных для отображения.

Структура этой главы построена так, что мы начнем рассмотрение построения доступа к данным с обзора механизма Object Relation Mapping, его истории, развития и того, какие механизмы ORM присутствуют в .NET. Мы рассмотрим технологию LINQ, LINQ для SQL, Entity Framework. После этого на простом примере разберем принцип организации эффективного доступа к данным в проектах ASP.NET MVC. В конце главы вас ждет раздел, в котором описаны наиболее популярные механизмы доступа к данным.

Задача получения доступа к данным из кода программы достаточно неординарна по своей природе. С одной стороны, нам хотелось бы иметь возможность оперировать сущностями данных, например, при наличии сущности "Заказчики" (таблица Customers), мы бы хотели иметь в коде возможность оперировать списками заказчиков, иметь возможность добавлять, удалять и изменять данные заказчиков. С другой стороны, мы бы не хотели, чтобы происходило смешивание кода бизнес-логики с такими данными, как строки SQL-запросов, что может привести к самым плачевным последствиям: от нечитабельности кода до непонятных и трудно диагностируемых ошибок или дыр в безопасности в виде SQL-инъекций. Чтобы избежать этого, мы хотели бы отказаться от написания запросов к нашему источнику данных на свойственном базе данных языке (например, построение строк SQL-запросов или разбор XML-файлов), внедрив некую прослойку между данными и операциями над ними. Такой прослойкой, которая с одной стороны предоставит нам полный контроль над данными, а с другой, позволит оперировать над ними в нужном нам стиле, становится ORM.

ORM — это аббревиатура от Object Relation Mapping или, по-русски, объектно-реляционная проекция. Очень легко объяснить сущность ORM: это механизм, который отображает на объекты объектно-ориентированного языка программирования сущности источника данных. Таким образом, одна запись таблицы Customers реляционной СУБД отображается в класс Customer в вашем коде (рис. 3.1).

Рис. 3.1. Отображение сущности базы данных в класс на языке C#

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

□ высокий порог вхождения для новичка, тогда как использование распространенного стороннего ORM предполагает большую вероятность того, что новичок знаком с ним;

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

Эти минусы в реальной жизни почти всегда перевешивают выгоду от собственного контроля над кодом ORM и заточенности под какие-то свои нужды.

Поэтому сторонние универсальные ORM получили такое широкое распространение.

ORM — не настолько старая технология, как можно было бы подумать. Трудно сказать достоверно, но, возможно, самым первым ORM, получившим широкое распространение, был продукт TopLink для языка программирования Smalltalk. Тогда этот проект принадлежал компании The Object People, название которой и легло в основу названия продукта. TopLink для SmallTalk вышел в 1994 году, а уже в 1996 году появилась версия для Java, которая называлась соответственно TopLink для Java. На сегодняшний момент, после серии покупок, TopLink принадлежит компании Oracle, которая продолжает выпускать его для Java-разработчиков.

Следующими за TopLink в очередности ORM-продуктов можно считать Java Database Objects и Entity Beans, первые версии которых появились в конце 90-х—начале 2000-х годов. Как нетрудно заметить, на ранних стадиях ORM как технология развивалась в основном в Java-среде.

Но самой значимой вехой в истории ORM можно считать появление продукта Hibernate, который был разработан сообществом Java-программистов под руководством Гэвина Кинга (Gavin King). Позднее компания JBoss наняла ведущих разработчиков Hibernate для развития и поддержки проекта. Еще позднее JBoss стала частью компании Red Hat, которая до сих пор поддерживает проект Hibernate.

С ростом популярности .NET-платформы самая известная ORM-библиотека была портирована и на .NET, получив название NHibernate. Последняя версия NHibernate 2.0.1 вышла в конце 2008 года, на момент написания книги известно, что версия 3.0 проекта находится в разработке и будет использовать .NET 3.5-функционал, в том числе и LINQ, о котором речь пойдет далее.

На данный момент ORM-библиотеки реализованы для многих популярных платформ и языков программирования: С++, Delphi, PHP, Python, Ruby, Perl, в чем можно убедиться, если посмотреть статью про ORM в Wikipedia. Для каждого из языков на текущий момент существует несколько, если не сказать множество, разнообразных ORM. Так, только для одной платформы .NET существует около тридцати разнообразных ORM-библиотек, что наглядно иллюстрирует современный тренд к повсеместному использованию ORM в разработке проектов любой сложности.

Компания Microsoft также представила свои решения в области ORM, ими стали LINQ для SQL и Entity Framework. Работа с обеими библиотеками производится с помощью интегрированного языка запросов LINQ, о котором и пойдет речь далее.

Технология LINQ

Технология LINQ или Language Integrated Query, что можно перевести как "интегрированные в язык запросы", появилась на свет вместе с выходом .NET Framework 3.5 в ноябре 2007 года. Как и многие другие наработки Microsoft, LINQ первоначально прошла путь экспериментального проекта под названием С(омега).

Суть LINQ проста — дать возможность разработчикам единообразно работать с коллекциями и наборами данных из разных источников, будь то: базы данных, XML-файлы, коллекции в языке программирования. Для этих целей реализуется определенный LINQ-провайдер, вроде встроенных в .NET Framework LINQ для XML, LINQ для SQL, LINQ для объектов, LINQ для сущностей. Решению этой задачи поспособствовали добавленные в .NET Framework 3.5 языковые расширения. Например, в C# появились анонимные методы и лямбда-выражения, которые интенсивно используются в LINQ.

Рассмотрим простейший пример LINQ-выражения:

List<int> a = new List<int>(3);

a.Add(3);

a.Add(12) ;

a.Add(-l);

List<int> positive = a.Where(x => x >= 0).Select(x => x).ToList();

В данном примере создается коллекция типа List<int> (список целочисленных значений) и заполняется тремя значениями. Последняя строчка — это и есть работа LINQ-механизма, который, используя набор методов LINQ для объектов, позволяет нам выбрать все положительные значения (согласно условию лямбда-выражения) в другой список. Для сравнения посмотрите на фрагмент кода, который выполняет те же действия, но без использования LINQ:

List<int> a = new List<int>(3);

a.Add(3) ;

a.Add(12) ;

a.Add(-1);

List<int> positive = new List<int>();

foreach (int item in a)

{

if (item >= 0)

positive.Add(item) ;

}

То, для чего обычно требовалось несколько строк кода, циклы и условия, теперь можно записать одним выражением в одной строке. Это и есть суть LINQ. В языке C# существует альтернативный вариант записи LINQ-выражений, который выглядит так:

List<int> positive = (

from x in a

where x >= 0

select x

).ToList ();

Как можно заметить, этот вариант во многом похож на синтаксис SQL-запросов. Что и не удивительно, поскольку этот вариант разрабатывался с учетом потребности в написании таких запросов архитекторами SQL-баз данных и специалистов, привыкших к подобному синтаксису. В своих проектах вы можете использовать любой из вариантов либо смешивать их друг с другом. Как показывает практика, каждый из них предпочтителен в разных конкретных случаях.

Рассмотренный пример задействует в себе механизм LINQ для объектов, который позволяет оперировать с коллекциями и другими стандартными наборами данных. Но кроме него огромное значение при работе с данными играют два других LINQ-провайдера: LINQ для SQL и LINQ для сущностей, которые призваны поддержать работу с двумя отдельными друг от друга ORM: LINQ для SQL и Entity Framework.

LINQ для SQL

LINQ для SQL является встроенным в .NET Framework механизмом, что отличает его от появившегося немного позднее Entity Framework. Благодаря этой встроенной поддержке и удобным инструментам мэппинга базы данных, LINQ для SQL получил очень широкое распространение. Способствовало этому также простота работы с ORM и низкий порог вхождения для любого разработчика. Кроме того, для создания ORM-базы данных с помощью LINQ для SQL не требуется писать ни строчки кода (хотя такая возможность и присутствует). В помощь разработчикам был предложен мастер создания модели данных, который формирует особый DBML-файл и файл с необходимыми для мэппинга классами. От разработчика требуется только указать подключение к БД и выбрать необходимые таблицы, все остальное мастер берет на себя (рис. 3.2 и 3.3).

Дальнейшее использование полученной модели данных столь же простое. Разработчику необходимо создать контекст базы данных, внести изменения и подтвердить их. Продемонстрируем это на примере:

protected void DoSomethingWithCustomer(Guid someCustomerld)

{

MyDatabaseDataContext db = new MyDatabaseDataContext();

var customer = db.Customers.SingleOrDefault(

x => x.customerId == someCustomerId);

if (customer != null)

{

customer.name = "Заказчик 1";

db.SubmitChanges();

}

}

Рис. 3.2. Окно создания модели LINQ для SQL

Рис. 3.3. Добавление в LINQ для SQL таблицы Customer

Здесь создается контекст базы данных MyDatabaseDataContext, ищется пользователь с определенным идентификатором someCustomerid, если он найден, у него меняется наименование на Заказчик 1 и изменения вносятся в базу данных вызовом метода Submitchanges. Такой же код, но с использованием механизма ADO.NET, приведен в следующем фрагменте. Вы сами можете сравнить оба способа по требуемому количеству кода и простоте:

protected void DoSomethingWithCustomer(Guid someCustomerId)

{

using (SqlConnection conn = new SqlConnection(@"

Data Source=localhost;

Initial Catalog=BookMVC; Integrated Security=True"))

{

conn.Open();

SqlCommand cmd = new SqlCommand(@"

SELECT * FROM Customers

WHERE customerId = @customerId", conn);

cmd.Parameters.Add(

new SqlParameter("customerId", someCustomerId));

SqlDataReader reader = cmd.ExecuteReader();

if (reader.Read())

{

SqlCommand updateCmd = new SqlCommand(@"

UPDATE Customers SET name = @name

WHERE customerId = @customerId", conn);

updateCmd.Parameters.Add(

new SqlParameter(''name", "Заказчик 1"));

updateCmd.Parameters .Add(

new SqlParameter("customerId", someCustomerId));

updateCmd.ExecuteNonQuery();

}

reader.Close();

}

}

Простота LINQ для SQL послужила его широкой распространенности. Но вместе с тем, в LINQ для SQL существуют и свои минусы. Во-первых, не так редки ситуации, когда неверно или некорректно построенное разработчиком LINQ-выражение приводит к потерям в производительности, к выборке лишних данных, к расходу памяти. Кроме того, в LINQ для SQL отсутствуют такие механизмы, как прозрачный мэппинг таблиц, связанных друг с другом через промежуточную таблицу отношением "многие-ко-многим". Многие разработчики на веб-сайтах, блогах и других сетевых ресурсах критиковали LINQ для SQL как ORM Framework за недостатки, как в производительности, так и в функциональном плане. Некоторые из них утверждают, что LINQ для SQL вовсе нельзя считать полноценным ORM Framework, справедливо замечая, что в нем нет возможности, например, создавать комплексные типы или производить наследование типов. По сути своей LINQ для SQL скорее представляет собой строго типизированное представление базы данных SQL Server, чем полноценный механизм ORM. Еще один недостаток LINQ для SQL заключается в его привязке к SQL Server, как к единственно возможному источнику данных. Безусловно, для ORM это ограничение является огромным недостатком, поскольку на рынке представлено свыше десятка разнообразных баз данных.

Трудно сказать, было ли это ответным шагом или так и планировалось, но Microsoft спустя некоторое время анонсировала новую разработку, "честную" ORM, Entity Framework.

Entity Framework

Выход финальной версии Entity Framework произошел одновременно с выходом Service Pack 1 для Visual Studio 2008 и Service Pack 1 для .NET Framework 3.5 в августе 2008 года. Ранее доступный для бета-тестирования как отдельный продукт, с выходом обновлений, Entity Framework стал частью .NET Framework и Visual Studio, которая предложила средства для визуального моделирования мэппинга базы данных.

Entity Framework — это "настоящая" ORM, в которой присутствуют все те вещи, которых не хватало в LINQ для SQL. Здесь и поддержка комплексных типов, наследования типов и возможность создания моделей для любой БД (через специальный провайдер). Entity Framework описывается специальным файлом в формате EDM, который включает в себя трехуровневую архитектуру: концептуальный слой, схему источника данных и слой мэппинга, что представляет собой значительно более гибкое решение, чем одноуровневый вариант DBML-файлов LINQ для SQL. Работа с Entity Framework так же базируется на механизме LINQ, называемом LINQ для сущностей, который во многом схож с LINQ для SQL. Вместе со значительно улучшенным функционалом Entity Framework стала более требовательной к разработчику. Так, в ней пропали некоторые механизмы LINQ для SQL, например, так называемый механизм ленивой загрузки (Lazy Loading) данных, когда данные автоматически подгружаются по мере надобности.

Далее приведен пример этого случая:

MyDatabaseDataContext db = new MyDatabaseDataContext();

var orders = db.Customers.First().Orders;

В случае с LINQ для SQL этот код вернет данные в виде набора заказов первого заказчика в наборе данных, тогда как Entity Framework данных не вернет. Связано это с тем, что в первом случае работает механизм Lazy Loading, который подгружает данные заказов при обращении к ним. Тогда как в Entity Framework разработчик должен сам определить код, который подгрузит данные. Для того чтобы получить данные в Entity Framework, необходимо прямо их затребовать:

MyDatabaseDataContext db = new MyDatabaseDataContext(); var customer = db.Customers.First(); customer.Orders.Load(); // загружаем данные var orders = customer.Orders;

Этот пример наглядно демонстрирует разнонаправленность двух механизмов LINQ для SQL и Entity Framework, которая позволяет им существовать параллельно: если вам нужно отображение баз данных SQL Server на классы вашей бизнес-логики, чтобы все "просто работало", необходима скоростная разработка, и к гибкости ORM не предъявляются повышенные требования, то LINQ для SQL вполне может стать тем инструментом, который полностью удовлетворит ваши потребности. В случае же, когда к структуре модели данных и возможностям ORM предъявляются серьезные требования, вроде потенциальной поддержки разнообразных источников данных, то среди двух описанных ранее технологий Entity Framework — это то, что вам нужно.

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

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

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

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

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

Что дает такая схема, и зачем нужна дополнительная прослойка между ORM и бизнес-логикой приложения:

□ внедрение хранилища для типовых запросов, например, получения записи по идентификатору или получения всех заявок заказчика, позволит, с одной стороны, унифицировать получение таких данных, а с другой, сделает связь с ORM менее жесткой;

□ внедрение сервисов похоже на внедрение хранилищ, только реализующих логику управления данными. Например, хорошей практикой является определение сервиса, который добавляет, изменяет либо удаляет данные. Обращаясь к такому сервису, ваш код не будет зависеть от реализации функций, существующей ORM и даже базы данных;

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

Возможность замены источника данных

Для более наглядного примера потребности в промежуточном коде и необходимости предусматривать возможные изменения в работе с ORM приведем случай из практики одного из авторов книги. Компания, в которой он работал, разрабатывала крупный проект, работающий с использованием SQL Server 2000. После нескольких лет разработки и поддержки, заказчик пожелал сменить SQL Server на другую СУБД. В связи с тем, что код проекта был жестко завязан на особенностях SQL Server, такой переход стоил больших усилий всего персонала компании.

В то время еще не существовало LINQ для SQL, но даже если бы компания использовала этот ORM, ей все равно пришлось бы переписывать подавляющую часть кода работы с данными в связи с тем, что LINQ для SQL не поддерживает ничего, кроме SQL Server.

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

Реализация слоя данных

Создадим простейший слой для работы с базой данных, который отвечал бы всем нашим требованиям. Для начала возьмем простую структуру базы данных (рис. 3.5).

Рис. 3.5. Структура базы данных

У нас есть три таблицы: заказчики, заказы и товары. Каждая из таблиц содержит набор свойственных ей полей, так в таблице Products (товары) есть поле isAvailible, которое показывает, доступен ли товар в настоящее время. У таблицы Orders (заказы) есть поля count — количество товара в штуках и orderDateTime — дата и время оформления заказа. Таблица Customers (заказчики) содержит информацию о заказчике.

Для реализации хранилищ и сервисов нам необходимы интерфейсы данных, определим их так, как показано в листинге 3.1.

Листинг 3.1. Интерфейсы данных

public interface ICustomer {

Guid CustomerId { set; get; }

string Name { set; get; }

string Phone { set; get; }

string Address { set; get; }

}

public interface IOrder {

Guid OrderId { set; get; }

Guid CustomerId { set; get; }

Guid ProductId { set; get; }

int Count { set; get; }

DateTime OrderDateTime { set; get; }

}

public interface IProduct {

Guid ProductId { set; get; }

string Name { set; get; }

bool IsAvailible { set; get; }

bool Cost { set; get; }

}

Воспользуемся мастером создания модели LINQ для SQL, чтобы сгенерировать классы для работы с базой данных. Посмотрим на сгенерированный код для таблицы Customers (приведен только фрагмент кода):

public partial class Customer : INotifyPropertyChanging,

INotifyPropertyChanged

{

private System.Guid _customerId;

private string _name;

private string _address;

private string _phone;

private EntitySet<Order> _Orders;

public Customer()

{

// код

}

[Column(Storage="_customerId",

DbType="UniqueIdentifier NOT NULL",

IsPrimaryKey=true)] public System.Guid customerId {

get { return this._customerId; }

set { // код }

}

[Column(Storage="_name",

DbType="NVarChar(250) NOT NULL", CanBeNull=false)]

public string name {

get { return this._name; }

set { // код }

}

[Column(Storage="_address",

DbType="NVarChar(1024) NOT NULL",

CanBeNull=false)]

public string address {

get { return this._address; }

set { // код }

}

[Column(Storage="_phone", DbType="NVarChar(250)")]

public string phone {

get { return this._phone; }

set { // код }

}

[Association(Name="Customer_Order",

Storage="_Orders", ThisKey="customerId",

OtherKey="customerId")]

public EntitySet<Order> Orders {

get { return this._Orders; }

set { this._Orders.Assign(value); }

}

}

Полученный код примечателен тем, что класс Customer является partial-классом, а это значит, что мы можем легко расширить его, и все прочие классы, для поддержки наших интерфейсов. Создадим частичные классы для реализации интерфейсов на базе LINQ для SQL так, как показано в листинге 3.2.

Листинг 3.2. Частичные классы с реализацией интерфейсов

public partial class Customer : ICustomer {

public Guid CustomerId {

get { return customerId; }

set { customerId = value; }

}

public string Name {

get { return name; }

set { name = value; }

}

public string Phone {

get { return phone; }

set { phone = value; }

}

public string Address {

get { return address; }

set { address = value; }

}

}

public partial class Order : IOrder {

public Guid OrderId {

get { return orderId; }

set { orderld = value; }

}

public Guid Customerld {

get { return customerId; }

set { customerId = value; }

}

public Guid ProductId {

get { return productId; }

set { productId = value; }

}

public int Count {

get { return count; }

set { count = value; }

}

public DateTime OrderDateTime {

get { return orderDateTime; }

set { orderDateTime = value; }

}

}

public partial class Product : IProduct {

public Guid ProductId {

get { return productId; }

set { productId = value; }

}

public string Name {

get { return name; }

set { name = value; }

}

public bool IsAvailable {

get { return isAvailable; }

set { isAvailable = value; }

}

public decimal Cost {

get { return cost; }

set { cost = value; }

}

}

На этом этапе существует еще одна полезная возможность, которую предлагает инъекция дополнительного кода: вы можете назначать имена для свойств интерфейса, не привязываясь к именам, которые определены в базе данных. Скажем, для поля cost таблицы Products мы могли бы задать другое название, например, ProductCost.

После реализации интерфейсов создадим простейшие хранилища и сервисы, для этого сначала объявим их интерфейсы:

public interface ICustomerRepository {

ICustomer GetCustomerById(Guid customerId);

IEnumerable<ICustomer> GetCustomersByProduct(Guid productId);

}

Хранилище для заказчиков позволит выбирать заказчика по идентификатору и выбирать всех заказчиков, связанных с определенным товаром.

public interface IOrderRepository {

IOrder GetOrderById(Guid orderId);

IEnumerable<IOrder> GetCustomerOrders(Guid customerId);

}

Хранилище для заказов позволит выбирать заказ по идентификатору и список заказов определенного заказчика.

public interface IProductRepository {

IProduct GetProductById(Guid productId);

IEnumerable<IProduct> GetAvailableProducts();

IEnumerable<IProduct> GetProductListByName(string name);

}

Хранилище для товаров позволит найти товар по идентификатору, список товаров по наименованию и список товаров, которые доступны в данный момент.

Реализация данных хранилищ не составляет труда (листинг 3.3).

Листинг 3.3. Реализация хранилищ

public class CustomerRepository : ICustomerRepository {

private readonly MyDatabaseDataContext _dataBase;

public CustomerRepository(MyDatabaseDataContext db)

{

if (db == null)

throw new ArgumentNullException("db");

_dataBase = db;

}

public ICustomer GetCustomerById(Guid customerId)

{

if (customerId == Guid.Empty)

throw new ArgumentException("customerId");

return _dataBase.Customers

.SingleOrDefault(x => x.customerId == customerId);

}

public IEnumerable<ICustomer> GetCustomersByProduct(Guid productId) {

if (productId == Guid.Empty)

throw new ArgumentException("customerId");

return _dataBase.Orders

.Where(x => x.productId == productId)

.Select<Order, ICustomer>(x => x.Customer).Distinct();

}

}

public class OrderRepository : IOrderRepository {

private readonly MyDatabaseDataContext _dataBase;

public OrderRepository(MyDatabaseDataContext db)

{

if (db == null)

throw new ArgumentNullException("db");

_dataBase = db;

}

public IOrder GetOrderByld(Guid orderld)

{

if (orderId == Guid.Empty)

throw new ArgumentException("orderId");

return _dataBase.Orders

.SingleOrDefault(x => x.orderId == orderId);

}

public IEnumerable<IOrder> GetCustomerOrders(Guid customerId)

{

if (customerId == Guid.Empty)

throw new ArgumentException("customerId");

return _dataBase.Orders

.Where(x => x.customerId == customerId)

.Select<Order, IOrder>(x => x);

}

}

public class ProductRepository : IProductRepository {

private readonly MyDatabaseDataContext _dataBase;

public ProductRepository(MyDatabaseDataContext db)

{

if (db == null)

throw new ArgumentNullException("db");

_dataBase = db;

}

public IProduct GetProductById(Guid productId)

{

if (productId == Guid.Empty)

throw new ArgumentException("productId");

return _dataBase.Products

.SingleOrDefault(x => x.productId == productId);

}

public IEnumerable<IProduct> GetAvailableProducts()

{

return _dataBase.Products.Where(x => x.isAvailable)

.Select<Product, IProduct>(x => x);

}

public IEnumerable<IProduct> GetProductListByName(string name)

{

if (string.IsNullOrEmpty(name))

throw new ArgumentException("name");

return _dataBase.Products

.Where(x => x.name.Contains(name))

.Select<Product, IProduct>(x => x);

}

}

Далее создадим сервисы, которые будут помогать нам манипулировать данными. Сначала определим интерфейсы сервисов:

public interface ICustomerService {

ICustomer Create(string name, string phone, string address);

void Delete(ICustomer customer);

void Update(ICustomer customer, string name,

string phone, string address);

}

public interface IOrderService {

IOrder Create(ICustomer customer, IProduct product, int count,

DateTime orderDateTime);

void Delete(IOrder order);

void Update(IOrder order, ICustomer customer,

IProduct product, int count, DateTime orderDateTime);

}

public interface IProductService {

IProduct Create(string name, bool isAvailable, decimal cost);

void Delete(IProduct product);

void Update(IProduct product, string name,

bool isAvailable, decimal cost);

Реализуем интерфейсы сервисов, как показано в листинге 3.4, для класса customerService. Чтобы уменьшить количество кода, приводить реализацию для других классов мы не будем, для остальных классов определяем методы Create, Delete и Update точно таким же образом.

Листинг 3.4. Реализация интерфейсов сервисов

public class CustomerService : ICustomerService {

private readonly MyDatabaseDataContext _database;

public CustomerService(MyDatabaseDataContext db)

{

if (db == null)

throw new ArgumentNullException("db");

_database = db;

}

public ICustomer Create(string name, string phone, string address)

{

if (String.IsNullOrEmpty(name))

throw new ArgumentNullException("name");

Customer customer = new Customer()

{

CustomerId = Guid.NewGuid(),

Address = address,

Phone = phone,

Name = name

};

_database.Customers.InsertOnSubmit(customer);

return customer;

}

public void Delete(ICustomer customer)

{

if (customer == null)

throw new ArgumentNullException("customer");

_database.Customers.DeleteOnSubmit((Customer)customer);

}

public void Update(ICustomer customer, string name,

string phone, string address)

{

if (customer == null)

throw new ArgumentNullException("customer");

if (String.IsNullOrEmpty(name))

throw new ArgumentNullException("name");

customer.Name = name;

customer.Phone = phone;

customer.Address = address;

}

}

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

public class UnitOfWork : IDisposable {

private readonly MyDatabaseDataContext _database;

public MyDatabaseDataContext DataContext {

get

{

return _database;

}

}

private bool _disposed;

public UnitOfWork()

{

_database = new MyDatabaseDataContext();

}

public void Commit()

{

_database.SubmitChanges();

}

public void Dispose()

{

Dispose(true); GC.SuppressFinalize(this);

}

private void Dispose(bool disposing) {

if (!this._disposed)

{

if (disposing)

{

_database.Dispose();

}

_disposed = true;

}

}

}

Этот класс реализует паттерн UnitOfWork, который описывает реализацию атомарного действия, в данном случае создание контекста базы ORM, использование, сохранение изменений и разрушение объекта.

Пример использования слоя данных

Наша инъекция кода полностью реализована, рассмотрим вариант использования:

using (UnitOfWork unitOfWork = new UnitOfWork())

{

ICustomerService customerService = new

CustomerService(unitOfWork.DataContext);

IOrderService orderService = new

OrderService(unitOfWork.DataContext);

IProductService productService = new

ProductService(unitOfWork.DataContext);

ICustomer customer = customerService.Create("Hoвый заказчик",

"111-22-33", "Адрес нового заказчика");

IProduct product = productService.Create("Новый товар", true, 50000);

orderService.Create(customer, product, 200, DateTime.Now);

unitOfWork.Commit();

}

Обратите внимание, в приведенном коде нет ни одной зависимости, которая привязывала бы нас либо к конкретной базе данных, либо к конкретному механизму ORM. Для замены одного из этих элементов нам потребуется всего лишь реализовать служебные механизмы вроде класса unitofWork, хранилищ и сервисов, согласно требованиям, но не приведенный код. Любой код, написанный с использованием описанных ранее механизмов, не потребует модернизации.

Еще одним хорошим ходом могло бы стать вынесение класса UnitofWork и контекста ORM в отдельные слабосвязанные сущности, для того чтобы хранилища и сервисы не были завязаны на определенные контексты ORM. Но в связи с тем, что хранилища и сервисы, по своей сути, жестко связаны с конкретным ORM, реализация такого вынесения требуется редко.

Механизмы для работы с данными

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

XML-данные

.NET Framework предлагает широкий ассортимент объектов для доступа к XML-данным, которые расположены в стандартных сборках: System.Xml, System.Xml.XPath, System.Xml.Xsl, System.Xml.Schema и System.Xml.Linq. Рассмотрим назначение и наиболее полезные классы каждой из сборок:

□ System.Xml — содержит базовые классы для работы с XML, такие как

XmlDocument, XmlElement, XmlNode и множество других, которые позволяют реализовать загрузку из файлов, обработку, добавление, изменение, удаление XML-данных;

□ System.Xml.XPath — содержит классы для реализации работы механизма XPath, позволяющего писать выражения к XML-документу для поиска необходимых данных;

□ System.Xml.Xsl — содержит классы для поддержки реализации XSLT-преобразований XML-документа;

□ System.Xml.Schema — содержит классы для поддержки XSD-схем и валидации XML-данных на их основе. Содержит большое число классов, позволяющих создавать XSD-схемы и использовать их;

□ System.Xml.Lin —  последняя сборка, которая недавно появилась в .NET Framework. Содержит классы, реализующие механизм доступа к XML-данным на основе LINQ-выражений. Этот механизм носит собственное название LINQ для XML. Он позволяет использовать уже известные вам LINQ-выражения для обработки XML-данных.

Рассмотрим пример обработки XML-данных с помощью LINQ для XML. Предположим, что у нас есть следующий XML-файл:

<?xml version="1.0"?>

<Orders>

<Order OrderId="99" OrderDateTime="01.02.2009">

<Address>

<Name>Владимир Иванов</Name>

<Street>yn. CTpoMTanefr</Street>

<House>12</House>

<Apartment>23</Apartment>

<City>MocKBa</City>

<Zip>100888</Zip>

<Country>Россия</Country>

</Address>

</Order>

<Order OrderId="100" OrderDateTime="01.02.2009">

<Address>

<Name>Сергей Петров</Name>

<Street>ул. Бажова</Street>

<House>76</House>

<Apartment>123</Apartment>

<City>Eкатеринбург</City>

<Zip>620000</Zip>

<Country>Россия</Country>

</Address>

</Order>

</Orders>

Для получения имени по номеру ордера, используя LINQ для XML, мы можем написать следующий код:

XDocument xdoc =

XDocument.Load("D:\\CPS\\#Projects\\MVCBook\\MVCBook\\Order.xml");

IEnumerable<XElement> orders =

xdoc.Element("Orders").Descendants("Order");

int orderId = 100;

IEnumerable<XElement> order =

orders.Where(x => x.Attribute("OrderId").Value == orderId.ToString());

XElement address = order.Select(x => x.Element("Address"))

.FirstOrDefault();

string name = address.Element("Name").Value;

В данном примере загружается файл orders.xml, в переменной orders присваиваются все заявки (элементы Order в XML-файле). Затем с помощью LINQ-запроса находится заявка с идентификатором 100. После этого выбирает элемент адреса заявки и, в завершение, из адреса извлекается имя.

Стоит отметить, что в данном примере не производились проверки возвращаемых значений на null, что на практике делать обязательно.

Работа с данными через ADO.NET

Понятие ADO.NET на платформе .NET достаточно широкое. На самом деле LINQ для SQL и LINQ для XML, а также все остальные стандартные LINQ-реализации входят в механизм ADO.NET как составные части. Но исторически ADO.NET развивалось от версии к версии платформы через другие механизмы, такие как объекты Dataset.

Dataset — это объект, содержащий кэш данных, загруженных из источника данных. По сути Dataset — это набор объектов типа DataTable, представляющих собой таблицы данных, и DataRelation, которые описывают связи между объектами DataTable.

Практически весь функционал по работе с данными через Dataset расположен в .NET Framework в пространствах имен System.Data и System.Data.OleDb (кроме этого, существует еще более двух десятков пространств имен, название которых начинается с System.Data). Перечислим основные самые важные классы, которые используются чаще всего при работе с Dataset из System.Data:

□ DataSet, DataTable, DataColumn, DataRow — различные варианты представления данных (набор, таблица, схема колонки, строка данных);

□ ConstraintCollection, Constraint, UniqueConstraint — представляют ограничения, которые могут быть наложены на объекты DataColumn.ConstraintCollection содержит набор таких ограничений для объекта DataTable;

□ DataView — объект, позволяющий привязывать данные из DataTable к формам WinForms или WebForms;

Список наиболее часто используемых классов пространства имен System.Data.OleDb:

□ OleDbConnection — обеспечивает подключение к базе данных через механизм OLE DB;

□ oleDbCommand — содержит запрос к базе данных на языке SQL либо представляет хранимую процедуру;

□ oleDataAdapter — обеспечивает заполнение объекта DataSet нужными данными с помощью элементов OieDbCommand;

□ oleDbDataReader — позволяет читать данные, полученные от oieDataAdapter, в виде строк и в прямом порядке;

□ oleDbTransaction — представляет собой транзакцию в источнике данных.

Существует еще одно часто используемое пространство имен, которое может быть полезно при разработке баз данных на SQL Server — System.Data.SqlClient. Это пространство имен содержит весь функционал System.Data.OleDb, только в реализации для использования исключительно с SQL Server. Применение этого пространства имен позволяет получить доступ к особенностям SQL Server, таким как новые типы данных SQL Server 2008.

Рассмотрим пример доступа к данным посредством базовых механизмов ADO.NET DataSet:

SqlConnection conn = new

SqlConnection("Data Source=localhost,

Initial Catalog=BookMVC, Integrated Security=True");

conn.Open();

SqlCommand cmd = new SqlCommand("SELECT * FROM Customers", conn);

SqlDataReader reader = cmd.ExecuteReader();

string phone;

while (reader.Read())

{

string name = reader["name"].ToString();

if (name == "Сергей Петров")

{

phone = reader["phone"].ToString();

break;

}

}

reader.Close();

conn.Close();

Данный пример инициализирует строку соединения с базой данных и открывает соединение. Затем создает команду в виде SQL-запроса на чтение всех записей из таблицы Customers (заказчики). С помощью ExecuteReader команда выполняется, и для работы с данными строится объект SqlDataReader. После этого формируется цикл, который проходит по всем записям, ищет первую запись с именем Сергей Петров и прерывает цикл, сохраняя данные о телефоне в локальной переменной.

Для сравнения перепишем этот простой пример, используя LINQ для Dataset:

SqlConnection conn = new SqlConnection(@"

Data Source=localhost;

Initial Catalog=BookMVC;

Integrated Security=True");

conn.Open();

SqlCommand cmd = new SqlCommand("SELECT * FROM Customers", conn);

DataSet ds = new DataSet();

SqlDataAdapter adapter = new SqlDataAdapter(cmd);

adapter.Fill(ds);

DataTable customers = ds.Tables[0];

string phone = customers. AsEnumerable()

.Where(x => x.Field<string>("name") == "Сергей Петров")

.Select(x => x.Field<string>("phone")).SingleOrDefault();

conn.Close();

Как нетрудно заметить, наш цикл, нацеленный на поиск данных, исчез, и ему на замену пришло LINQ-выражение, которое выполняет точно ту же логику — ищет телефон по определенному номеру.

Механизм доступа к данным через ADO.NET Dataset в общем случае производительнее, чем через ORM, вроде LINQ для SQL или Entity Framework, поскольку при работе с объектами типа Dataset нет затрат на реализацию объектной модели базы данных. Работа с данными происходит напрямую через SQL-запросы или вызов хранимых процедур. Разработчик сам контролирует весь процесс получения и использования данных, что дает больше возможностей и прирост производительности, но с другой стороны, увеличивает объем написания необходимого кода.

Поскольку основная часть времени при запросе тратится на его выполнение, то использование ADO.NET вместо популярных ORM для доступа к данным оправдано только там, где ставятся повышенные требования к потреблению памяти и производительности. В большинстве же случаев затраты на ORM окупаются скоростью и простотой разработки, единой моделью доступа к данным и меньшему количеству кода.

LINQ для SQL

Работа с LINQ для SQL на платформе .NET Framework осуществляется с помощью классов пространства имен System.Linq и System.Data.Linq.

Перечислим основные классы этих пространств имен.

□ System.Linq:

• Enumerable — предоставляет набор статичных методов для работы с объектами, реализующими интерфейс IEnumerable<T>.

• Queryable — предоставляет набор статичных методов для работы с объектами, реализующими интерфейс IQueryable<T>.

Методы этих классов, вроде Where, Select, Sum и др., используются в любом LINQ-выражении для построения запросов, обработки и фильтрации данных.

□ System.Data.Linq:

• DataContext — основной объект для работы с LINQ для SQL, предоставляет контекст базы данных, через который осуществляется доступ ко всем сущностям базы данных;

• EntitySet<TEntity>, EntityRef<TEntity> (структура) — обеспечивают связь между сущностями в LINQ для SQL;

• Table<TEntity> — представляет таблицу с возможностью изменения объектов;

• CompiledQuery — предоставляет возможность компилировать и повторно использовать запросы.

Контекст базы данных, наследующий от класса DataContext, в LINQ для SQL принято создавать с помощью мастера, который автоматически сгенерирует LINQ для SQL-классов. После такой генерации работа с объектной моделью становится очень простой, например, приведенный в разделе ADO.NET пример в исполнении LINQ для SQL будет выглядеть так:

using (MyDatabaseDataContext dataContext = new MyDatabaseDataContext())

{

string phone = dataContext.Customers

.Where(x => x.name == "Сергей Петров")

.FirstOrDefault().phone;

}

Согласитесь, это заметно более простое решение по сравнению с вариантом, написанным с использованием ADO.NET Dataset.

Entity Framework

Entity Framework можно использовать только на .NET Framework версии 3.5 с установленным пакетом обновления SP1. Для работы с Entity Framework предлагаются следующие пространства имен: System.Data.Entities, System.Data.Objects, System.Data.EntityClient и др.

В отличие от LINQ для SQL модель данных Entity Framework (EDM) состоит из трех частей:

□ концептуальная модель (CSDL) — позволяет создавать сущности, не равнозначные сущностям базы данных, например, комплексные сущности, состоящие из элементов нескольких таблиц, или сущности, наследующие от других сущностей;

□ модель хранения данных (SSDL) — определяет логическую модель базы данных;

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

При работе с Entity Framework в Visual Studio 2008 SP1 предлагается мастер автоматического создания модели на базе заданных объектов базы данных. Вы можете использовать его для генерации всех трех частей EDM. Результатом работы мастера станет файл *.edmx, который будет содержать все три модели сразу. Контекст базы данных и отображение на классы C# будут сгенерированы в другой файл *.Designer.cs.

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

Другим отличием Entity Framework от LINQ для SQL является разнообразие доступа к модели данных. Существует три варианта работы с EDM:

□ LINQ для сущностей — аналог LINQ для SQL с полной поддержкой всех особенностей Entity Framework;

□ Entity SQL — особенный язык, диалект SQL, который служит для работы с моделью EDM. Имеет ряд отличий и ограничений по сравнению с обычным SQL;

□ третий вариант совмещает в себе первые два, с помощью LINQ-выражений можно строить запросы на языке Entity SQL.

Подробное описание особенностей Entity Framework или Entity SQL выходит за рамки этой книги. Здесь мы приведем только очевидные отличия LINQ для сущностей от LINQ для SQL:

□ поддержка прозрачного мэппинга отношений "многие-ко-многим" в LINQ для сущностей. LINQ для SQL строго отображает структуру базы данных, поэтому промежуточная таблица также будет отображена, и ее потребуется использовать при работе с такими данными;

□ отсутствие в LINQ для сущностей поддержки методов Single и singleOrDefault, вместо которых рекомендуется использовать First и FirstOrDefault;

□ вместо методов DeleteOnSubmit и SubmitChanges в LINQ для сущностей предложены методы DeleteObject и saveChanges соответственно;

□ вместо метода XXX.InsertOnSubmit предложены обертки (автогенерируемые) AddToXXX, где XXX — это имя отображаемой сущности (таблицы).

Еще одно незначительное отличие в процессе автогенерации моделей с помощью мастеров в Visual Studio представляет собой изменение имени таблицы при отображении на класс в LINQ для SQL. Например, таблица Customers отобразится на класс Customer, без последней буквы "s". При создании классов в Entity Framework мастер не производит такие изменения.

NHibernate

Еще одним вариантом организации доступа к данным может стать популярная ORM-библиотека NHibernate — довольно старый механизм, портированный на платформу .NET Framework из Java-проекта Hibernate. Как ORM, Hibernate давно заслужила право называться зрелой, гибкой, мощной и главное производительной библиотекой. Адаптация под .NET, хотя и не совсем полностью реализует функционал Hibernate версии 3, но предлагает все тот же механизм, сравнимый по мощности и производительности с предком.

NHibernate, как и другие ORM, использует для реализации доступа к данным мэппинг в виде XML-файла. Этот файл должен быть оформлен согласно схеме nhibernate-mapping.xsd, которая идет в комплекте поставки. По традиции названия всех таких файлов мэппинга формируются как class_name.hbm.xml. Такой файл может выглядеть примерно так:

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn: nhibernate-mapping-2.2"

namespace="MyNamespace" assembly="MyNamespace">

<class name="Customer" table="Customers">

<id name="customerId">

<column name="customerId" not-null="true" />

<generator class="guid"/>

</id>

<property name="name" />

<property name="phone" />

<property name="address" />

</class>

</hibernate-mapping>

Здесь создается мэппинг класса Customer на таблицу Customers в базе данных, которая содержит ряд полей: customerId, name, phone, address. Для подключения к базе данных должен быть создан другой конфигурационный файл, похожий на этот:

<?xml version="1.0" encoding="utf-8"?>

<hibernate-configuration>

<session-factory xmlns="urn: nhibernate-configuration-2.2">

<property name=''connection.provider">

NHibernate.Connection.DriverConnectionProvider

</property>

<property name=''connection.driver_class">

NHibernate.Driver.SqlClientDriver

</property>

<property name="dialect">

NHibernate.Dialect.MsSql2005Dialect

</property>

<property name="connection.connection_string">

Server=(local);

Initial Catalog=MyDatabase;

Integrated Security=SSPI;

</property>

<mapping resource="MyNamespace.Customer.hbm.xml"

assembly="MyNamespace" />

</session-factory>

</hibernate-configuration>

К сожалению, для NHibernate отсутствует встроенная автоматизация генерации отображаемого кода и модели данных, а также файлов конфигурации. Поэтому описание модели ложится на плечи разработчика. С одной стороны, это рутинные операции, которые машина сделает лучше, но с другой, такой подход предоставляет разработчику больший простор для реализации его идей. Впрочем, в Интернете есть проекты с открытым исходным кодом, призванные облегчить и этот и другие процессы при работе с NHibernate:

□ Fluent NHibernate (http://fluentNHibernate.org/);

□ MyGeneration (http://www.mygenerationsoftware.com/portal/default.aspx);

□ NHibernate 1.2 Generator (http://gennit.com/);

□ NHibernate Query Generator

(http://ayende.com/projects/downloads/NHibernate-query-generator.aspx);

□ NHibernate Entity Generator (http://www.softpedia.com/get/Programming/Other-Programming-Files/NHibernate-Entity-Generator.shtml);

□ NHibernate Helper Kit (http://www.codeproject.com/KB/dotnet/NHibernate_Helper_Kit.aspx);

□ многие другие (http://stackoverflow.com/questions/41752/nhibernate-generators).

Для работы с NHibernate используются пространства имен NHibernate и NHibernate.Cfg. Второе служит для загрузки файла конфигурации, например, как показано в следующем примере:

ISessionFactory sessionFactory = new Configuration()

.Configure("Nhibernate.cfg.xml").BuildSessionFactory();

где Nhibernate.cfg.xml — ваш файл конфигурации.

NHibernate основывается на объектах ISession, которые представляют собой пользовательскую сессию подключения к базе данных, поэтому для работы с данными необходимо создать экземпляр ISession. В качестве примера работы с NHibernate можно привести такой шаблон кода:

ISession session;

ITransaction tran;

try

{

session = sessionFactory.OpenSession();

tran = session.BeginTransaction();

// делаем какую-то работу

tran.Commit();

session.Close();

}

catch (Exception ex)

{

tran.Rollback();

session.Close();

}

Как вы можете заметить, NHibernate реализует механизм транзакций с возможностью откатывать ненужные изменения.

Работа с объектами NHibernate возможна с помощью одного из трех вариантов:

□ Hibernate Query Language (HQL) — языка во многом похожего на язык LINQ c SQL-синтаксисом;

□ Query By Criteria (QBC) — объектный вариант, который позволяет строить выражения запросов динамически через объектно-ориентированный API;

□ через обыкновенные SQL-запросы.

Приведем простой пример использования HQL:

string result = (string)session.createQuery(@"select phone

from Customer as c

where c.name = 'Сергей Иванов'").UniqueResult();

Пример вернет телефон заказчика по его имени. Перепишем этот пример с использованием Query By Criteria:

ICriteria crit = session.CreateCriteria(typeof(Customer));

crit.Add(Expression.Eq("name", "Сергей Иванов"));

crit.SetMaxResults(1);

string phone = (string) crit.UniqueResult();

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

Кроме того, в будущих версиях NHibernate может появиться полноценная поддержка LINQ. По крайней мере, частичная реализация уже существует в NHibernate Contrib (https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/trunk/). Эта возможность позволит оперировать NHibernate-объектами в привычном для LINQ-разработчиков стиле и, наверняка, увеличит привлекательность библиотеки.

Сравнение механизмов доступа к данным

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

□ удобство и единообразие доступа к данным;

□ объем кода, который может стать источником ошибок;

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

И, хотя понятие простоты субъективно, все же мы можем попытаться оценить описанные технологии по простоте работы:

□ на первом месте LINQ для SQL, как простой, но все-таки эффективный Framework для отображения структуры базы данных на код;

□ NHibemate и Entity Framework на втором месте по простоте, как механизмы схожие во многом с LINQ для SQL, но все-таки в силу своей комплексности и обширным возможностям более сложны при построении слоя доступа к данным;

□ более сложным вариантом построения механизма доступа к данным является использование ADO.NET либо других методов, вроде прямого доступа к XML-файлам. Этот вариант требует поддержки большого объема самописного кода, большого внимания к его написанию, он потенциально более незащищен в связи с возможными уязвимостями.

Рекомендации по выбору механизма доступа к данным

Используйте низкоуровневые механизмы, вроде ADO.NET, в тех проектах, где скорость доступа к данным — это основная задача, и главное требование к проекту — высокая производительность. Для проектов, ориентированных на SQL Server, которые не предполагают высоконагруженной работы с данными или не содержат сложной структуры базы данных, вполне возможно использовать LINQ для SQL. В случае, когда простоты LINQ для SQL не хватает, либо используется база данных, отличная от SQL Server, хорошим решением станет один из ORM Entity Framework или NHibernate, в зависимости от ваших пристрастий и предпочтений.

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

ГЛАВА 4

Контроллеры

В паттерне MVC контроллеры выполняют следующие последовательные функции:

□ контроллер реагирует на действия клиента, например: нажатие кнопки отправки формы на сервер, Ajax-запросы, которые генерирует браузер, и др.;

□ контроллер оперирует с моделью, изменяя ее состояние;

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

Назначение контроллеров

Обзор контроллеров в ASP.NET MVC

Для разработчика ASP.NET MVC-контроллер представляет собой класс, унаследованный от базового класса Controller (который в свою очередь унаследован от класса ControllerBase, реализующего интерфейс IController). Каждый файл контроллера MVC Framework должен подчиняться следующим требованиям:

□ располагаться в папке Controllers корня проекта;

□ иметь суффикс Controller, например HomeController.cs, AccountController.cs;

□ класс контроллера должен иметь то же название, что и файл:

HomeController, AccountController.

Каждый контроллер содержит набор методов, которые в терминах MVC Framework называются действиями (actions). Действия реализуют бизнес-логику ответа и изменение модели данных в зависимости от действия пользователя или запроса клиента. Действия всегда возвращают результат, реализующий класс, наследующий ActionResult: такими классами являются следующие стандартные типы: ViewResult, JsonResult, FileResult, RedirectResult, RedirectToRouteResult, ContentResult, EmptyResult. В зависимости от возвращаемого типа клиент получит тот или иной тип набора данных: HTML-страницу, JSON-данные, бинарный файл и др. Кроме того, MVC Framework позволяет определять вам свои собственные определения типа возвращаемых значений.

Для примера рассмотрим проект ASP.NET MVC, который создается по умолчанию:

□ в файле AccountController.cs определен класс-контроллер AccountController, который содержит набор методов, возвращающих результат типа ActionResult;

□ класс AccountController, кроме всего прочего, содержит методы LogOn, LogOff, Register, ChangePassword и ChangePasswordSuccess, которые являются действиями, возвращающими результат типа ActionResult;

□ действия этого класса возвращают разнообразные типы значений. Так, большинство действий возвращают результат типа ViewResult, вызывая стандартный метод View. Некоторые методы могут вернуть результат в виде RedirectResult с помощью вызова метода Redirect или RedirectToRouteResult с помощью RedirectToAction;

□ в зависимости от типа возвращаемого значения пользователь получит определенный результат. Если метод вернул ViewResult, то пользователь получит HTML-код и увидит страницу. В случае когда результатом вызова действия будут данные типа RedirectResult, то браузер пользователя перенаправит вызов на другую страницу. В случае же когда тип возвращаемого значения — это RedirectToRouteResult, MVC Framework перенаправит вызов на другое действие текущего или иного контроллера.

Рассмотрим более конкретный пример, метод LogOn класса AccountController:

public ActionResult LogOn(string userName,

string password,

bool rememberMe,

string returnUrl)

{

if (!ValidateLogOn(userName, password))

{

return View () ;

}

FormsAuth.SignIn(userName, rememberMe) ;

if (!String.IsNullOrEmpty(returnUrl))

{

return Redirect(returnUrl);

}

else

{

return RedirectToAction("Index", "Home");

}

}

Этот метод представляет действие, которое в зависимости от полученных от пользователя данных производит авторизацию пользователя либо сообщает об ошибке авторизации. В данном случае выполняется проверка данных пользователя и, если они неверны, возвращается стандартное представление, сопоставленное данному действию. Если данные верны, происходит авторизация, и пользователь перенаправляется либо на главную страницу, либо на URL, указанный в параметре returnUrl. Перенаправление на главную страницу происходит через вызов метода RedirectToAction, который возвращает результат типа RedirectToRouteResult, перенаправление на другой URL происходит через вызов Redirect, который возвращает результат типа RedirectResult.

Простой пример реализации контроллера

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

Перед созданием нашего примера заполним базу данных пользователей данными:

□ добавим две роли пользователей: Administrators и Users;

□ добавим пользователей Admin с ролью Administrators и User с ролью Users.

Для добавления этих данных необходимо воспользоваться встроенным в Visual Studio средством для управления пользователями, которое можно вызвать, нажав последнюю иконку на панели Solution Explorer, которая появляется во время того, когда активен проект, реализующий поддержку стандартных провайдеров базы данных пользователей (рис. 4.1).

Рис. 4.1. Панель кнопок Solution Explorer

Для того чтобы создать контроллер в Visual Studio 2008, необходимо проделать следующие действия: в контекстном меню папки Controllers выбрать пункт Add, затем Controller (рис. 4.2).

Рис. 4.2. Пункт меню, позволяющий добавить в проект новый контроллер

В появившемся окне необходимо ввести название класса нового контроллера, в нашем случае AdminController (рис. 4.3).

После этого Visual Studio сгенерирует в пространстве имен по умолчанию необходимый нам класс:

public class AdminController : Controller {

//

// GET: /Admin/

public ActionResult Index() {

return View();

}

}

Рис. 4.3. Окно ввода имени контроллера

Visual Studio только облегчает вам жизнь, упрощая рутинные операции, но при желании вы могли бы создать этот класс самостоятельно.

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

public ActionResult Index()

{

if (User.IsInRole("Administrators"))

{

MembershipProvider mp = Membership.Provider;

int userCount;

var users = mp.GetAllUsers(0, Int32.MaxValue, out userCount);

ViewData.Model = users;

return View ();

}

else

{

return RedirectToAction("Index", "Home");

}

}

Здесь, после проверки на принадлежность текущего пользователя к группе Administrators, создается список зарегистрированных пользователей, после чего он передается в специальный объект viewData, который в MVC Framework содержит модель данных, необходимых для представления. Если пользователь прошел проверку на принадлежность к группе Administrators, то после создания набора действие завершится вызовом метода viewData, который сформирует представление, сопоставленное данному действию. В случае же, когда пользователь, не имеющий права на доступ к этому действию, вызовет его, действие перенаправит вызов на другое действие Index контроллера Home, что, по сути, означает перенаправление на главную страницу сайта.

Для отображения наших данных нам необходимо создать представление. В MVC Framework представление для контроллера должно создаваться по определенным правилам:

□ все представления для определенного контроллера должны находиться в папке, название которой повторяет название контроллера, например: Home, Account;

□ все такие папки должны находиться в папке Views, которая располагается в корне проекта или веб-сайта;

□ каждый отдельный файл представления должен иметь название, совпадающее с именем действия контроллера, которому оно соответствует, например LogOn.aspx, Register.aspx.

Согласно этим правилам создадим папку Admin в папке Views, в которую через контекстное меню добавим представление Index (рис. 4.4).

Рис. 4.4. Пункт меню, позволяющий добавить новое представление

Рис. 4.5. Окно создания нового представления

В окне Add View (рис. 4.5) необходимо указать название представления (без расширения файла), остальные параметры пока оставьте без изменения. Добавим разметку и код для формирования представления в файле Index.aspx:

<asp:Content ID="Content2"

ContentPlaceHolderID="MainContent"

runat="server">

<h1>Список пользователей</h1>

<p>

<table>

<tr>

<th></th>

<th>Имя</th>

<th>Email</th>

<th>Последняя активность</th>

<th>Подтвержден</th>

<th>Заблокирован</th>

</tr>

<% foreach

(MembershipUser user in

(MembershipUserCollection)ViewData.Model) { %>

<tr>

<td><%= Html.ActionLink("Выбрать",

"Select",

new {userid = (Guid)user.ProviderUserKey}) %>

</td>

<td><%= Html.Encode(user.UserName) %></td>

<td><%= Html.Encode(user.Email) %></td>

<td><%= user.LastActivityDate %></td>

<td><%= user.IsApproved %></td>

<td><%= user.IsLockedOut %></td>

</tr>

<% } %>

</table>

</p>

</asp:Content>

Теперь мы можем запустить проект и посмотреть на результат работы. Для этого нам необходимо войти в систему под пользователем Admin и перейти по адресу http://"наш сайт"/Admin. Если вы все сделали правильно, то результатом будет примерно такой список пользователей — рис. 4.6.

Рис. 4.6. Список пользователей

Для завершения создания контроллера реализуем все остальные необходимые действия так, как показано в листинге 4.1.

Листинг 4.1. Действия контроллера AdminController

public ActionResult Select(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

if (User.IsInRole("Administrators"))

{

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

ViewData.Model = user;

return View () ;

}

else

{

return RedirectToAction("Index", "Home");

}

}

public ActionResult Update(Guid? userId,

string email,

bool isApproved,

bool isLockedOut)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

if (User.IsInRole("Administrators"))

{

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

user.Email = email; user.IsApproved = isApproved;

if (user.IsLockedOut && !isLockedOut)

user.UnlockUser();

mp.UpdateUser(user);

return RedirectToAction("Index");

}

else

{

return RedirectToAction("Index", "Home");

}

}

public ActionResult Delete(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

if (User.IsInRole("Administrators"))

{

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

mp.DeleteUser(user.UserName, true);

return RedirectToAction("Index");

}

else

{

return RedirectToAction("Index", "Home");

}

}

В листинге 4.1 определено три действия для отображения данных конкретного пользователя, удаления данных и сохранения новых данных. Обратите внимание, что действия Update и Delete не возвращают сопоставленного представления, а только перенаправляют запрос на вызов других действий с имеющимися представлениями. Только действие Select возвращает сопоставленное представление. Давайте создадим соответствующее представление для контроллера Admin, назвав его Select, и определим его следующим образом:

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<%=Html.ActionLink("Вернуться в список", "Index")%>

<% MembershipUser user = (MembershipUser) ViewData.Model; %>

<h1>Пользователь <%= Html.Encode(user.UserName) %></h1>

<% using (Html.BeginForm("Update", "Admin")) { %>

<%= Html.Hidden("userId", (Guid)user.ProviderUserKey) %>

<fieldset>

<legend>Данные</legend>

<p>

<label for="email">Email</label>

<%=Html.TextBox("email", user.Email)%>

</p>

<p>

<label for="isApproved"><%=Html.CheckBox("isApproved",

user.IsApproved)%>подтвержден</label>

</p>

<p>

<label for="isLockedOut"><%=Html.CheckBox("isLockedOut",

user.IsLockedOut)%>заблокирован</label>

</p>

</fieldset>

<input type="submit" value="Сохранить" />

<%=Html.ActionLink("Удалить", "Delete", new {userId = (Guid)

user.ProviderUserKey})%>

<% } %>

</asp:Content>

Когда вы запустите проект, то после входа под логином Admin и перехода на страницу администрирования, вы сможете выбирать пользователей путем перехода по ссылкам Выбрать. После такого перехода для пользователя User вы должны увидеть следующую форму (рис. 4.7).

Рис. 4.7. Форма редактирования данных пользователя

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

Архитектура контроллеров

Мы рассмотрели простейший вариант создания контроллеров и их действий, а также сопоставленных с ними представлений. Но архитектура MVC Framework помимо рассмотренных механизмов содержит массу больших и малых механизмов, которые позволяют регулировать контроллеры, управлять вызовами кода, защищать контроллеры и действия от нежелательных вызовов, формировать базовые архитектуры для набора действий или даже группы контроллеров.

Далее мы более подробно рассмотрим архитектуру реализации контроллеров в MVC Framework. По мере рассмотрения, наш простейший код будет видоизменяться согласно новым техникам, о которых будет идти рассказ.

Порядок вызова архитектурных механизмов

ASP.NET MVC реализует следующий порядок выполнения внутренних механизмов:

1. При первом обращении к приложению в Global.asax производится регистрация маршрутов механизма маршрутизации ASP.NET в специальном объекте RouteTable.

2. С помощью urlRoutingModule производится маршрутизация запроса с использованием созданных маршрутов, при этом выбирается первый подходящий маршрут, после чего создается объект типа RequestContext.

3. Обработчик MvcHandler, с помощью данных полученного объекта RequestContext, инстанцирует объект фабрики контроллеров типа IControllerFactory. Если он не был задан специально, по умолчанию инстанцируется объект класса DafaultControllerFactory.

4. В фабрике контроллеров вызывается метод GetControllerInstance, который принимает параметр в виде типа необходимого контроллера. Этот метод возвращает инстанцированный объект необходимого контроллера.

5. У полученного объекта контроллера вызывается метод Execute, которому передается объект RequestContext.

6. С помощью ActionInvoker, свойства класса Controller типа ControllerActionInvoker, определяется необходимое действие и выполняется его код. Если ActionInvoker специально не сопоставлен, то используется свойство ActionInvoker по умолчанию. Для инициализации параметров действия используется механизм Model Binding, который может быть переопределен.

7. Определение действия может быть изменено в случае, когда пользователь определил для действий атрибуты типа ActionMethodSelectorAttribute. Для каждого такого атрибута вызывается метод IsValidForRequest, которому передается набор параметров типа ControllerContext и MethodInfo. Метод IsValidForRequest возвращает результат в виде bool, который определяет, подходит ли выбранное действие для исполнения в контексте запроса.

8. Выполнение действия может быть отменено, изменено или пропущено, если пользователь определил для действия атрибуты типа FilterAttibute. Такие атрибуты могут использоваться для определения прав доступа, кэширования результатов, обработки исключений.

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

10. В случае когда Actioninvoker был специально переопределен, то после вызова действия результат действия передается методу CreateActionResult свойства Actioninvoker, который волен переопределить возвращаемый результат действия и вернуть результат типа ActionResult.

11. В случае, когда Actioninvoker не был переопределен, действие должно вернуть результат выполнения в виде ActionResult.

12. Для результата типа ActionResult вызывается метод ExecuteResult, который осуществляет отображение результата для контекста запроса. Создав свой вариант класса, наследующий ActionResult и реализующий ExecuteResult, можно переопределить действие и возвращать результат в нужном виде, например, формировать RSS-ленту.

Рассмотрим все шаги, относящиеся к контроллерам и действиям, более подробно. Для этого выделим основные темы:

□ фабрика контроллеров;

□ действия, фильтры и атрибуты;

□ механизм Model Binding.

Фабрика контроллеров

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

Фабрика контроллеров — это механизм, созданный с одной целью — создавать экземпляры контроллеров. В ASP.NET MVC фабрика контроллеров — это один из механизмов, который позволяет настроить поведение механизма MVC под себя, расширить функционал, предоставить разработчику возможность гибкой настройки действия MVC.

Фабрика контроллеров в ASP.NET реализует интерфейс IControllerFactory, который содержит всего два метода:

public interface IControllerFactory {

IController CreateController(RequestContext requestContext,

string controllerName);

void ReleaseController(IController controller);

}

Здесь CreateController должен создавать экземпляр контроллера, а ReleaseController — разрушать его или проводить какие-то другие действия после завершения работы контроллера. Вы можете создать свою фабрику контроллеров, реализовав этот интерфейс. Но более простым способом расширения фабрики является ее реализация с помощью наследования от класса DefaultFactoryController.

Для примера рассмотрим такую, вполне возможную задачу, решить которую позволит фабрика контроллеров:

□ необходимо создать механизм, который позволит ограничивать создание определенных контроллеров на основе "черного списка";

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

□ решение на базе маршрутов не может нас удовлетворить в связи с тем, что у нас много универсальных маршрутов, которые затрагивают сразу много контроллеров;

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

Согласно этим требованиям создадим фабрику контроллеров, которая позволит нам ограничивать выполнение контроллеров по их именам через XML-файл "черного списка". Вот пример такого файла:

<?xml version="1.0" encoding="utf-8" ?>

<blacklist>

<item typeName="AccountController" />

<item typeName="AdminController" />

</blacklist>

Как можно увидеть, данным файлом мы хотели бы заблокировать выполнение контроллеров AccountController и AdminController.

Реализуем фабрику контроллеров, наследуя класс DefaultFactoryController:

public class ControllerFactory : DefaultControllerFactory {

protected override IController

GetControllerInstance(Type controllerType)

{

if (controllerType == null)

return base.GetControllerInstance(controllerType);

XmlDocument xdoc = new XmlDocument();

string blacklistPath =

HttpContext.Current.Server.MapPath("~/blacklist.xml");

xdoc.Load(blacklistPath);

XmlNodeList nodes = xdoc.GetElementsByTagName("blacklist");

foreach (XmlNode node in nodes[0].ChildNodes)

{

if (node.Attributes["typeName"].Value == controllerType.Name)

throw new HttpException(404, "Страница не найдена");

}

return base.GetControllerInstance(controllerType);

}

}

Как вы можете видеть, единственным методом нашего класса является реализация перегруженного метода GetControllerInstance класса DefaultControllerFactory. В нем мы реализуем следующую последовательность действий:

1. Проверяем, не передается ли в фабрику контроллера типа контроллера в виде null, если это так, то завершаем выполнение вызовом базового метода для выполнения действия по умолчанию.

2. Загружаем наш XML-файл с "черным списком" и ищем в нем имя типа контроллера, который запрошен для создания.

3. Если в "черном списке" существует запись о блокировании данного контроллера, то возвращаем ответ на запрос в виде 404 ошибки HTTP "Страница не найдена".

4. Если контроллер отсутствует в "черном списке", то мы выполняем базовое действие по умолчанию для поиска и создания необходимого контроллера.

Для того чтобы наш код заработал, мы должны зарегистрировать нашу фабрику контроллеров. Функцию регистрации выполняет метод SetControllerFactory класса controllerBuilder. Добавим его вызов в файл Global.asax:

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

ControllerBuilder.Current.SetControllerFactory( new ControllerFactory());

}

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

Другим, пожалуй, самым распространенным вариантом использования фабрики контроллеров является реализация архитектурного паттерна Инверсия контроля (Inversion of Control), который в данном применении позволяет в приложении уменьшить зависимость и ослабить связи между контроллерами. Для реализации такого механизма используются сторонние библиотеки, вроде Unity Application Blocks от Microsoft, Spring.NET или Ninject.

Действия, фильтры и атрибуты

Переопределение свойства Actionlnvoker

После того как фабрика контроллеров создала контроллер, производится вызов его метода Execute, который с помощью специального свойства ActionInvoker определяет необходимый метод для выполнения действия и вызывает его. По умолчанию ActionInvoker создается как экземпляр класса ControllerActionInvoker, но разработчик волен переопределить его. Переопределение ActionInvoker — это еще одна точка расширения ASP.NET MVC, которой вы можете воспользоваться для самых разнообразных целей. Например, т. к. именно ActionInvoker исполняет все необходимые фильтры типа ActionFilter, то вы вольны изменить этот механизм для того, чтобы часть фильтров не могла быть использована для ваших контроллеров в некотором гипотетическом случае.

По умолчанию метод InvokeAction класса ActionInvoker вместе с самим вызовом действия реализует механизм обработки заданных через атрибуты фильтров для действия.

Всего InvokeAction формирует четыре группы фильтров:

□ ActionFilters — вызываются во время исполнения действия;

□ ResultFilters — вызываются после исполнения действия при обработке результата;

□ AuthorizationFilters — вызываются до исполнения действия, чтобы произвести проверку доступа;

□ ExceptionFilters — вызываются во время обработки возникшего исключения.

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

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

Листинг 4.2

public class FastControllerActionInvoker : ControllerActionInvoker

{

public override bool InvokeAction(

ControllerContext controllerContext, string actionName)

{

if (controllerContext == null)

throw new ArgumentNullException("controllerContext");

if (String.IsNullOrEmpty(actionName))

throw new ArgumentException("actionName");

ControllerDescriptor controllerDescriptor =

GetControllerDescriptor(controllerContext);

ActionDescriptor actionDescriptor = FindAction(controllerContext,

controllerDescriptor, actionName);

if (actionDescriptor != null)

{

IDictionary<string, object> parameters =

GetParameterValues(controllerContext, actionDescriptor);

var actionResult = InvokeActionMethod(controllerContext,

actionDescriptor, parameters);

InvokeActionResult(controllerContext, actionResult);

return true;

}

return false;

}

}

Существенное достоинство этого класса в том, что уменьшение затрат на вызов действия позволило ускорить вызов в среднем на величину от 5 до 30 % по разным оценкам проведенного нами тестирования. С другой стороны, данный вариант не поддерживает многие стандартные механизмы MVC: фильтры, обработку ошибок, проверку авторизации.

Для использования нового класса FastControllerActionInvoker нужно присвоить его экземпляр свойству ActionInvoker необходимого контроллера. Например, используем наш новый класс для контроллера AccountController стандартного проекта MVC:

public AccountController()

: this(null, null)

{

ActionInvoker = new FastControllerActionInvoker();

}

Атрибуты ActionMethodSelectorAttribute

Мы рассмотрели работу механизма ControllerActionInvoker, который призван найти и выполнить необходимое действие контроллера. Одной из особенностей этого поиска является поиск установленных для действий атрибутов типа ActionMethodSelectorAttribute. Эти атрибуты имеют одно-единственное предназначение — определение того, может ли быть вызвано это действие в данном контексте запроса или нет. Рассмотрим определение класса ActionMethodSelectorAttribute:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false,

Inherited = true)]

public abstract class ActionMethodSelectorAttribute : Attribute {

public abstract bool IsValidForRequest(

ControllerContext controllerContext,

MethodInfo methodInfo);

}

Как вы видите, атрибут содержит только один метод IsValidForRequest, который возвращает булево значение, определяющее, может ли быть вызвано помеченное действие. Этот атрибут очень полезен для обеспечения безопасности, т. к. позволяет "спрятать" часть методов от любой возможности неправомерного использования.

Для удобства разработчиков MVC Framework уже реализует два атрибута, наследующих от ActionMethodSelectorAttribute:

□ AcceptVerbsAttribute — позволяет задать для действия допустимые типы HTTP-запросов из следующего списка: GET, POST, PUT, DELETE, HEAD. Запросы, отличные от указанных, будут игнорироваться;

□ NonActionAttribute — позволяет пометить метод, не являющийся действием. Такой метод невозможно будет вызвать никаким внешним запросом.

Используем эти атрибуты для нашего контроллера AdminController. Так как действия Index, Select и Delete могут быть вызваны только GET-запросами, пометим их соответствующим атрибутом, как показано в следующем фрагменте:

[AcceptVerbs(HttpVerbs.Get)]

public ActionResult Index()

[AcceptVerbs(HttpVerbs.Get)]

public ActionResult Delete(Guid? userId)

[AcceptVerbs(HttpVerbs.Get)]

public ActionResult Select(Guid? userId)

Наоборот, действие Update вызывается только POST-запросами, поэтому пометим их следующим образом:

[AcceptVerbs(HttpVerbs.Post)]

public ActionResult Update(Guid? userId, string email,

bool isApproved, bool isLockedOut);

Теперь, если мы попытаемся вызвать действие Update из строки запроса браузера, набрав URL вроде такого http://localhost:5434/Admin/Update, то получим ошибку с сообщением о том, что страница не была найдена. Без атрибута AcceptVerbs метод был бы вызван.

Для демонстрации действия атрибута NonActionAttribute проведем некоторые изменения в нашем коде. Обратите внимание на то, что в методах класса ActionController повторяется следующий код:

User.IsInRole("Administrators")

Вынесем его в отдельный метод UserlsAdmin:

[NonAction]

private bool UserIsAdmin()

{

return User.IsInRole(''Administrators");

}

Обратите внимание, что мы пометили этот метод атрибутом NonAction, который указывает на то, что данный метод не является действием и не может быть выбран механизмом MVC при поиске в контроллере необходимого действия.

Атрибуты, производные от FilterAttribute

Когда механизм MVC находит необходимое для вызова действие, производится поиск и выполнение ряда атрибутов, которые являются производными от атрибута FilterAttribute. Такие атрибуты называются фильтрами и в основном предназначены для проверки прав вызова и безопасности контекста запроса. MVC Framework содержит ряд таких атрибутов, которые вы можете использовать в своих проектах:

□ AuthorizeAttribute — позволяет указывать ограничения для имен пользователей и ролей, которые могут вызвать данное действие;

□ HandleErrorAttribute — позволяет определять действия для обработки необработанных исключений;

□ ValidateAntiForgeryTokenAttribute — проверяет контекст запроса на соответствие указанному маркеру безопасности при получении данных из форм;

□ ValidateInputAttribute — управляет механизмом проверки запроса на небезопасные значения. Позволяет отключить такого рода проверку для случаев, когда требуется получить данные разного вида, в том числе потенциально опасные.

AuthorizeAttribute

AuthorizeAttribute — весьма полезный атрибут, который позволяет задавать группы и пользователей, имеющих доступ к заданному действию контроллера или ко всему контроллеру сразу. В нашем примере для проверки прав на доступ к действию контроллера AdminController мы создали следующий метод:

[NonAction]

private bool UserIsAdmin()

{

return User.IsInRole("Administrators");

}

С использованием атрибута AuthorizeAttribute нужда в этом методе пропадает. Чтобы продемонстрировать действие AuthorizeAttribute, перепишем контроллер AdminController по-новому, так, как показано в листинге 4.3.

Листинг 4.3

public class AdminController : Controller

{

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Roles = "Administrators")]

public ActionResult Index()

{

MembershipProvider mp = Membership.Provider;

int userCount;

var users = mp.GetAllUsers(0, Int32.MaxValue, out userCount);

ViewData.Model = users;

return View () ;

}

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Roles = "Administrators")]

public ActionResult Select(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

ViewData.Model = user;

return View () ;

}

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Roles = "Administrators")]

public ActionResult Update(Guid? userId, string email,

bool isApproved, bool isLockedOut)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

user.Email = email; user.IsApproved = isApproved;

if (user.IsLockedOut && !isLockedOut)

user.UnlockUser();

mp.UpdateUser(user);

return RedirectToAction("Index");

}

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Roles = "Administrators")]

public ActionResult Delete(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

mp.DeleteUser(user.UserName, true);

return RedirectToAction("Index");

}

}

Как вы можете заметить, мы избавились от рутинной операции проверки права доступа к действию контроллера путем задания для каждого действия атрибута [Authorize(Roles = "Administrators")]. Этот атрибут предписывает механизму MVC выполнить проверку права доступа пользователя при попытке вызвать действие нашего контроллера. Важным достоинством данного атрибута является его элегантность и унификация. Вместо того чтобы самим писать такой важный код, как код проверки прав доступа, мы оперируем механизмом метаданных в виде атрибута AuthorizeAttribute, помечая нужные нам участки кода. Так снижается возможность ошибки программиста, которая в случае работы с задачей безопасности может стоить очень дорого. Другим плюсом использования атрибута AuthorizeAttribute является заметное уменьшение кода, особенно в сложных вариантах, когда требуется предоставить доступ набору групп и пользователей.

Атрибут AutorizeAttibute принимает два параметра:

□ Roles — позволяет задавать перечисление ролей, которые имеют доступ к действию, через запятую;

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

Так, например, следующий фрагмент кода определяет, что доступ к действию могут получить только члены группы Administrators и пользователи SuperUserl и SuperUser2:

[Authorize(Roles = "Administrators", Users = "SuperUserl, SuperUser2")]

HandleErrorAttibute

Атрибут HandleErrorAttribute предназначен для того, чтобы однообразно сформировать механизм обработки необработанных в контроллерах исключений. Атрибут HandleErrorAttribute применим как к классу контроллера, так и к любому действию. Кроме того, допустимо указывать атрибут несколько раз. По умолчанию, без параметров, механизм MVC с помощью атрибута HandleErrorAttribute при возникновении исключения произведет переадресацию на представление Error, которое должно находиться в папке -/Views/Shared. Однако это действие можно изменить под свои потребности. Для манипулирования порядком действия атрибута HandleErrorAttribute у него есть ряд параметров:

□ ExceptionType — указывает тип исключения, на возникновение которого должен реагировать данный атрибут;

□ View — указывает представление, которое нужно показать пользователю при срабатывании атрибута;

□ Master — указывает наименование Master View, которое будет использоваться при демонстрации пользователю представления;

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

Для демонстрации работы атрибута HandleErrorAttribute создадим представление AdminError, которое будет использоваться только тогда, когда произойдет ошибка при работе с контроллером AdminController. В листинге 4.3 представлен код представления.

<%@ Page Title="" Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Ошибка! Произошло необработанное исключение.

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<% var model = (HandleErrorlnfo)ViewData.Model; %>

<h2>Внимание</h2>

<р>При работе сайта произошла исключительная

ситуация в действии <%= model.ActionName %>

контроллера <%= model.ControllerName %>.

Ниже представлена дополнительная информация об исключении:

</p>

<p><%= model.Exception.Message %></p>

<p><%= model.Exception.StackTrace %></p>

</asp:Content>

Обратите внимание, для получения доступа к расширенной информации об исключении мы используем свойство Model объекта ViewData, предварительно приведя его к типу HandleErrorInfo. Механизм атрибута HandleErrorAttribute создает для представления элемент типа HandleErrorInfo, объект которого содержит следующие данные:

□ ActionName — имя действия, в котором произошло исключение;

□ ControllerName — имя контроллера, в котором произошло исключение;

□ Exception - объект типа Exception, в котором содержится вся информация об исключении, в том числе строка сообщения и трассировка стека.

Для того чтобы проверить наше представление, создадим для тестирования новое действие TestException в контроллере AdminController:

public ActionResult TestException()

{

throw new Exception("Проверка исключения");

}

Пометим наш контроллер AdminController атрибутом HandleErrorAttribute в следующем виде, как это показано во фрагменте:

[HandleError(View = "AdminError")]

public class AdminController : Controller

Теперь, чтобы механизм атрибута HandleErrorAttribute заработал, необходимо включить механизм Custom Errors в файле web.config так, как показано во фрагменте:

<customErrors mode="On" />

После запуска приложения и попытки доступа к действию TestException мы получим сообщение об ошибке (рис. 4.8).

Кроме перечисленного, атрибут HandleErrorAttribute имеет ряд важных особенностей:

□ если механизм Custom Errors запрещен, или исключение уже было обработано другим атрибутом, то исполнение атрибута прекращается;

□ если исключение является HTTP-исключением с кодом, отличным от 500, исполнение атрибута прекращается. Другими словами, этот атрибут не обрабатывает HTTP-исключения с любыми кодами ошибок, кроме 500;

□ атрибут устанавливает Response.TrySkipIisCustomErrors = true для того, чтобы попытаться переопределить страницы веб-сервера, настроенные для отображения ошибок;

□ атрибут устанавливает код HTTP-ответа в значение 500, которое сообщает клиенту о возникшей при запросе ошибке.

Использование атрибута HandleErrorAttribte позволяет гибко настраивать реакцию вашего приложения на возникновение исключительных ситуаций.

Вы можете определять для каждого контроллера, действия или типа исключения свои представления вывода информации об ошибке.

ValidateAntiForgeryTokenAttribute

Проблема безопасности в современном Интернете не заканчивается вместе с проверкой права доступа на базе неких правил, ролей или пользователей.

Вместе с возможностями защиты от несанкционированного доступа изменяются и способы проникновения и взлома защиты. Одним из таких способов проникнуть через защиту сайта является атака под названием Cross-site Request Forgery Attack (CSRF). Суть этой атаки заключается в следующем:

□ сайт должен иметь авторизацию по cookies, а пользователь, через которого планируется атака, должен иметь возможность автоматической авторизации;

□ на некой специальной странице в Интернете создается элемент формы со скрытыми параметрами и автоматическим отправлением этих данных по адресу сайта, на котором зарегистрирован пользователь;

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

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

Механизм ASP.NET MVC имеет поддержку такого рода защиты в виде атрибута ValidateAntiForgeryTokenAttribute и helper-метода Html.AntiForgeryToken. В нашем примере с контроллером AdminController есть слабое и уязвимое место — это действие Delete, которое выполняется с помощью GET-запросов и может быть использовано злоумышленником для того, чтобы преднамеренно удалять данные о пользователях. Правильно сформированные формы не должны разрешать любые модификации данных по GET-запросам. Иными словами, GET-запросы должны выполнять действия "только для чтения", а все остальные действия должны происходить через POST-запросы. Перепишем наш механизм действия Delete и добавим к нему и действию Update поддержку атрибута ValidateAntiForgeryTokenAttribute, для этого изменим разметку представления так, как показано в следующем фрагменте:

<% using (Html.BeginForm("Update", "Admin")) { %>

<%= Html.Hidden("userId", (Guid)user.ProviderUserKey) %>

<%= Html.AntiForgeryToken() %>

<fieldset>

<legend>Данные</legend>

<p>

<label for="email">Email</label>

<%=Html.TextBox("email", user.Email)%>

</Р>

<p>

<label for="isApproved"><%=Html.CheckBox("isApproved",

user.IsApproved)%>подтвержден

</label>

</p>

<p>

<label for="isLockedOut"><%=Html.CheckBox("isLockedOut",

user.IsLockeCOut)%>заблокирован

</label>

</p>

</fieldset>

<input type="submit" value="Сохранить" />

<% } %>

<% using(Html.BeginForm("Delete", "Admin")) { %>

<%= Html.Hidden("userId", (Guid)user.ProviderUserKey) %>

<%= Html.AntiForgeryToken() %>

<input type="submit" va1ue="Удалить" />

<% } %>

Как вы можете заметить, к основной форме мы добавили поле Html.AntiForgeryToken(), а вместо ссылки для удаления создали еще одну форму, которая также защищена полем Html.AntiForgeryToken().

Теперь добавим поддержку защиты в наш контроллер AdminController для действий Update и Delete, как показано во фрагменте:

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Users = "Admin")]

[ValidateAntiForgeryToken]

public ActionResult Update(Guid? userId,

string email, bool isApproved, bool isLockedOut)

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Users = "Admin")]

[ValidateAntiForgeryToken]

public ActionResult Delete(Guid? userId)

Обратите внимание, что мы ограничили доступ к нашему обновленному действию Delete только для POST-запросов. Для защиты от CSRF-атак мы добавили атрибут ValidateAntiForgeryTokenAttribute. Это все, что нам нужно сделать, чтобы защитить данные формы от несанкционированного доступа.

Для более высокого уровня безопасности атрибуту ValidateAntiForgeryTokenAttribute можно передать параметр Salt ("соль"), который представляет собой числовое значение. Параметр Salt — это дополнительный секретный ключ, который используется при формировании итогового проверяемого значения, для повышения уровня защиты.

Для более гибкой настройки helper-метод Html.AntiForgeryToken имеет ряд параметров:

□ salt — задает значение Salt, которое используется в атрибуте ValidateAntiForgeryTokenAttribute;

□ domain — задает значение параметра Domain для объекта HttpCookie, указывающее конкретный домен, с которым ассоциирован cookie;

□ path — задает значение параметра Path для объекта HttpCookie, указывающее виртуальный путь, с которым ассоциирован cookie.

После наших исправлений в контроллере AdminController не осталось действий, которые манипулируют с данными по GET-запросам, а действия с POST-запросами защищены механизмом атрибута ValidateAntiForgeryTokenAttribute.

ValidateInputAttribute

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

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

ASP.NET MVC предлагает разработчику гибкий механизм управления проверкой параметров запроса. Для такого управления существует атрибут ValidateInputAttribute. Для демонстрации действия этого атрибута добавим в нашу форму редактирования параметров Select.aspx возможность редактирования поля Comment, которое будет содержать любой текст, в том числе и с HTML-разметкой. Данное поле будет выводиться вместе с отображаемым именем пользователя, играя роль сообщения для пользователя.

Изменим форму ввода, добавив следующий фрагмент кода:

<p>

<label for="comment">Комментарий</label>

<%=Html.TextArea("comment", user.Comment) %>

</p>

Соответственно изменим определение действия Update контроллера AdminController:

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Users = "Admin")]

[ValidateAntiForgeryToken]

public ActionResult Update(Guid? userId, string email,

string comment, bool isApproved, bool isLockedOut)

{

if (!userId.HasValue)

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

user.Email = email;

user.Comment = comment;

user.IsApproved = isApproved;

if (user.IsLockedOut && !isLockedOut) user.UnlockUser();

mp.UpdateUser(user);

return RedirectToAction("Index");

}

Для того чтобы пользователь видел сообщение, модифицируем частичное представление LogOnUserControl.ascx так, как показано в листинге 4.4.

Листинг 4.4. Представление LogOnUserControl.ascx

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<%

if (Request.IsAuthenticated) {

%>

Welcome <b><%= Html.Encode(Page.User.Identity.Name) %></b>!

[ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]

<p><%= Membership.GetUser(Page.User.Identity.Name).Comment %></p>

}

else {

%>

[ <%= Html.ActionLink("Log On", "LogOn", "Account") %> ]

<%

}

%>

После запуска попробуем добавить в поле комментария для любого из пользователей значение <b>добрый день! </b> и сохранить изменения. Так как механизм проверки ввода включен по умолчанию, мы получим сообщение об ошибке (рис. 4.9).

Чтобы отключить проверку ввода для данного действия, для него необходимо добавить атрибут validateinputAttribute так, как показано во фрагменте:

[AcceptVerbs(HttpVerbs.Post)]

[Authorize(Users = "Admin")]

[ValidateAntiForgeryToken]

[ValidateInput(false)]

public ActionResult Update(Guid? userId, string email,

string comment, bool isApproved, bool isLockedOut)

Атрибут ValidateInput с параметром false указывает механизму ASP.NET MVC на то, что проверка параметров запроса для данного действия не требуется. После указания этого значения атрибута мы сможем задавать для значения Comment данные с HTML-тегами. Сообщение будет выведено рядом с именем пользователя, как показано на рис. 4.10.

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

Атрибуты ActionFilterAttribute и OutputCacheAttribute

Существует еще один способ расширения механизма ASP.NET MVC. Через атрибут ActionFilterAttribute разработчик может задать выполнение кода по нескольким событиям, происходящим при работе механизма MVC. Вот следующие события, на которые можно реагировать с помощью определения атрибута ActionFilterAttribute: перед выполнением действия, после выполнения действия, перед исполнением результата и после исполнения результата.

Атрибут ActionFilterAttribute представляет собой абстрактный класс с четырьмя виртуальными методами: OnActionExecuting, OnActionExecuted, onResultExecuting, onResultExecuted. Реализация атрибута ложится на плечи разработчика. Обработка этих событий может быть полезна, например, для реализации механизма логов с целью вычисления времени исполнения действий. Другим вариантом использования может быть модификация HTTP-заголовков для ответа клиенту. Таким образом работает включенный в состав ASP.NET MVC атрибут OutputCacheAttribute.

OutputCacheAttribute предназначен для управления стандартными HTTP-заголовками, влияющими на кэширование веб-страниц браузером пользователя. Разработчикам классического ASP.NET этот механизм знаком по директиве @ OutputCache для ASPX-страниц и ASCX-компонентов. OutputCacheAttribute может быть определен как для класса контроллера, так и для отдельного действия. Для управления действием у OutputCacheAttribute есть ряд параметров:

□ Duration — значение времени в секундах, на которое производится кэширование;

□ Location — значение перечисления OutputCacheLocation, которое определяет местоположение для кэшированного содержимого: на стороне клиента или сервера. По умолчанию устанавливается значение OutputCacheLocation.Any, это означает, что содержимое может кэшироваться в любом месте;

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

□ VaryByCustom — любой текст для управления кэшированием. Если этот текст равен browser, то кэширование будет производиться условно по имени браузера и его версии (major version). Если у VaryByCustom будет указана строка, то вы обязаны переопределить метод GetVaryByCustomString в файле Global.asax для осуществления условного кэширования;

□ varyByHeader — строка с разделенными через точку с запятой значениями HTTP-заголовков, по которым будет производиться условное кэширование;

□ varyByParam — задает условное кэширование, основанное на значениях строки запроса при GET или параметрах при POST;

□ varyByContentEncodings — указывает условие кэширования в зависимости от содержимого директивы HTTP-заголовка Accept-Encoding;

□ CacheProfile — используется для указания профиля кэширования заданного через web.config и секцию caching;

□ NoStore — принимает булево значение. Если значение равно true, то добавляет в директиву HTTP-заголовка Cache-Control параметр no-store;

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

В качестве примера рассмотрим следующий фрагмент кода, в котором устанавливается кэширование 1800 секунд (30 минут) любого результата контроллера AdminController вне зависимости от параметров запроса:

[OutputCache(Duration = 1800, VaryByParam = ="none")]

public class AdminController : Controller

В другом фрагменте, наоборот, с помощью атрибута OutputCacheAttribute отключается любое кэширование результатов контроллера AdminController:

[OutputCache(Location = OutputCacheLocation.None)]

public class AdminController : Controller

В своей работе атрибут OutputCacheAttribute переопределяет метод OnResultExecuting, который вызывается перед исполнением результата действия, когда результат типа ActionResult преобразуется в ответ на запрос пользователя, например в HTML-страницу. Вы можете создать свои варианты реализации ActionFilterAttribute, реализовав атрибут, переопределяющий ActionFilterAttribute. Для демонстрации подобной реализации создадим атрибут, который реализует сжатие результирующих страниц с помощью GZip-сжатия, которое поддерживается всеми современными браузерами.

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

Листинг 4.5

using System;

using System.IO.Compression;

using System.Web.Mvc;

namespace MVCBookProject {

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method,

Inherited = true, AllowMultiple = false)]

public class GZipCompress : ActionFilterAttribute {

public override void OnActionExecuting(

ActionExecutingContext filterContext)

{

string acceptEncoding = filterContext.HttpContext.Request

.Headers["Accept-Encoding"];

if (string.IsNullOrEmpty(acceptEncoding)) return;

var response = filterContext.HttpContext.Response;

if (acceptEncoding.ToLower().Contains("gzip"))

{

response.AppendHeader("Content-encoding", "gzip");

response.Filter = new GZipStream(

response.Filter, CompressionMode.Compress);

}

}

}

}

Обратите внимание, что атрибут GZipCompressAttribute наследует от ActionFilterAttribute и реализует метод OnActionExecuting, в котором С Помощью класса GZipStream производится сжатие. Использование нашего атрибута тривиально, например, применяем его для контроллера AdminController так, как показано во фрагменте кода:

[GZipCompress]

public class AdminController : Controller

Реализация своего варианта ActionFilterAttribute — это очень мощное средство для расширения механизма ASP.NET MVC. Благодаря ему, мы реализовали прозрачное и простое средство для GZip-сжатия ответов для клиента. Другим стандартным средством, которое использует ActionFilterAttribute, является атрибут outputcacheAttribute, который позволяет управлять кэшированием результатов действий контроллера.

Стандартные реализации класса ActionResult

ActionResult — это базовый класс, экземпляр которого возвращает любое действие контроллера в ASP.NET MVC. В MVC существует несколько стандартных реализаций класса ActionResult: ViewResult, JsonResult, FileResult, RedirectResult, RedirectToRouteResult, ContentResult, EmptyResult. Их назначение и тип возвращаемых данных перечислены в табл. 4.1.

Когда действие завершает свое выполнение, оно возвращает результат в виде базового класса ActionResult или его наследников. После этого механизм MVC вызывает у возвращенного результата стандартный метод ExecuteResult, который и формирует результат, получаемый клиентом.

ViewResult

ViewResult — это стандартный и самый используемый на практике результат, наследующий тип ActionResult, который возвращается действиями контроллеров. Назначение ViewResult — это определение представления, которое будет использовано механизмом MVC для представления состояния модели.

У ViewResult и базового класса ViewResultBase, от которого ViewResult унаследован, есть ряд параметров:

□ ViewData — хранилище данных модели, которые используются представлением для отображения результата работы действия;

□ TempData — аналогичное viewData хранилище данных модели, но с существенным отличием, которое позволяет данным храниться после перенаправления запроса на другое действие;

□ viewName — имя представления, которое должно отреагировать на изменение модели контроллером. Иными словами, этот параметр указывает механизму MVC, какое представление нужно использовать для отображения результата работы действия;

□ MasterName — имя master-представления, которое должно быть использовано для отображения результата работы действия;

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

Обычно для возвращения результата типа viewResult из действия используется стандартный метод контроллера view, который принимает те же параметры, что и viewResult. Рассмотрим пример вызова метода view:

public ActionResult Select(Guid? userid)

{

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userId, false);

return view("Select", "Site", user);

}

В приведенном фрагменте действие Select возвращает результат типа viewResult, который формируется стандартным методом контроллера view. В данном случае метод view принимает три параметра: имя представления Select, имя master-представления Site и модель данных user.

JsonResult

JsonResult — это стандартная возможность механизма MVC возвращать результат на запрос пользователя в виде JSON-данных. JSON — это формат данных, название которого расшифровывается как JavaScript Object Notation или объектная нотация JavaScript. Хотя в названии присутствует слово JavaScript, формат данных JSON языконезависимый и может быть использован при разработке на любом языке.

Примечание

JSON является альтернативой другому формату данных — XML, но по сравнению с XML JSON более короткий, поэтому JSON получил распространение при совместном использовании с механизмом Ajax, когда размер передаваемых данных может иметь большое значение.

*********************************

Класс JsonResult содержит несколько свойств, для более гибкой настройки возвращаемого результата:

□ ContentEncoding — устанавливает значение HTTP-параметра ContentEncoding, который определяет кодировку возвращаемого результата;

□ ContentType — устанавливает значение HTTP-параметра ContentType, если не указано, то по умолчанию устанавливается в application/json;

□ Data — любые данные, которые могут быть сериализованы в формат JSON с помощью класса JavaScriptSerializer.

Использовать JsonResult для возвращения результата в виде JSON-данных очень просто, для этого в контроллере существует стандартный метод Json, который принимает все параметры JsonResult и возвращает готовый результат. Рассмотрим пример действия для контроллера AdminController, которое возвращает JSON-данные по запросу с параметром имени пользователя:

public JsonResult SelectUserData(string userName)

{

if (string.IsNullOrEmpty(userName))

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userName, false);

UserData userData = new UserData()

{

Comment = user.Comment,

Email = user.Email,

IsApproved = user.IsApproved,

IsLockedOut = user.IsLockedOut

};

return Json(userData, null, Encoding.UTF8);

}

В представленном фрагменте кода для передачи набора данных о пользователе в виде JSON-данных используется единственный метод Json, которому передается набор данных. Результатом, который получит пользователь в ответ, например, на такой запрос http://localhost:5434/Admin/SelectUserData?userName=admin будет текст в следующем формате:

{"UserId":null,"Email":"vyunev@live.ru","Comment":"","IsApproved":true, "IsLockedOut":false,"CurrentMembershipUser":null}

FileResult

Очень часто в ответ на запрос пользователя требуется вернуть не HTML-страницу или данные в формате JSON, а какой-нибудь бинарный файл. FileResult — это механизм, который как раз и позволяет возвратить файл как результат работы действия контроллера.

У FileResult есть два важных свойства, которые требуется указывать при возвращении результата действия:

□ contentType — свойство, которое задается через конструктор класса FileResult и не может быть изменено напрямую. ContentType указывает MIME-тип содержимого передаваемого файла;

□ FileDownloadName — свойство, указывающее на файл, который требуется передать в ответ на запрос.

Рассмотрим использование FileResult на следующем примере. Пусть нам требуется на пользовательский запрос возвращать сопоставленный с пользователем рисунок. Реализуем эту возможность с помощью файловой системы. Для этого создадим в корне проекта папку Admin, в которой будем хранить рисунки пользователей в формате PNG с именем вида: GUID пользователя.рng. Действие GetUserImage контроллера AdminController, которое будет возвращать изображение с помощью FileResult, представлено в следующем фрагменте:

public ActionResult GetUserImage(string userName)

{

if (string.IsNullOrEmpty(userName))

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userName, false);

if (user == null)

throw new HttpException(404, "Пользователь не найден");

string userGuidString = ((Guid) user.ProviderUserKey).ToString();

string fileName = userGuidString + ".png";

return File(fileName, "image/png");

}

Обратите внимание, что для возвращения результата типа FileResult в примере используется стандартный метод контроллера File, который упрощает возврат результата в виде FileResult. Методу File передается два параметра: путь к возвращаемому файлу и его MIME-тип, который в данном случае для PNG-файла равен image/png.

В MVC Framework существует еще один класс для работы с файлами — класс FileContentResult, который наследует от FileResult и позволяет возвращать данные не на основании пути к файлу, а с помощью существующего потока данных, который может генерироваться в самом действии.

RedirectResult и RedirectToRouteResult

Важным свойством MVC Framework является возможность перенаправлять запрос на другие действия контроллеров либо другие URL-адреса. Для этого в MVC встроены механизмы RedirectResult и RedirectToRouteResult, которые наследуют от ActionResult и являются допустимыми результатами работы любого действия.

RedirectResult предназначен для того, чтобы возвратить результат пользователю в виде перенаправления на заданный адрес URL. У RedirectResult есть только одно свойство, которое инициализируется через конструктор, — Url, оно указывает строку адреса, на которую будет перенаправлен пользователь в ответ на запрос. Контроллеры MVC содержат стандартный метод Redirect, который формирует ответ в виде RedirectResult. В следующем фрагменте приведено действие, результатом которого является перенаправление пользователя на сайт http://www.asp.net/mvc/:

public ActionResult GetAspNetSite()

{

return Redirect("http://www.asp.net/mvc/");

}

RedirectToRouteResult выполняет схожую по смыслу с RedirectResult логику, но перенаправление вызова RedirectToRouteResult производится только на основании маршрутов таблицы маршрутизации. RedirectToRouteResult имеет два конструктора, с разным числом параметров, всего параметров два:

□ routeName — указывает наименование маршрута, на который нужно выполнить перенаправление запроса;

□ routeValues — указывает набор значений параметров маршрута типа RouteValueDictionary, с помощью которых производится поиск маршрута и выполняется перенаправление.

Для упрощения работы с RedirectToRouteResult механизм MVC реализует для контроллеров, наряду с методами RedirectToRoute, набор стандартных методов RedirectToAction, которые призваны облегчить формирование перенаправления вызова на другие действия или контроллеры. Например, следующий фрагмент кода перенаправляет вызов из текущего действия в действие Index текущего контроллера:

return RedirectToAction("Index");

При использовании RedirectToAction можно указывать и контроллер, в который требуется перенаправить вызов, кроме того, можно указать набор значений параметров маршрута типа RouteValueDictionary. Следующий пример кода перенаправит вызов на действие Index контроллера AccountController:

return RedirectToAction("Index", "Account");

ContentResult

ContentResult — это весьма простая реализация ActionResult, которая предназначена для того, чтобы в ответ на запрос передавать любой пользовательский строковый набор данных. Для реализации логики у ContentResult есть три свойства:

□ ContentType — MIME-тип передаваемых в ответ на запрос данных;

□ ContentEncoding — кодировка данных;

□ Content — строка данных для передачи в ответ на запрос.

Благодаря ContentResult разработчик получает возможность генерировать ответы на запросы в любом виде, который можно представить в виде строки текста. Этот тип ActionResult может быть полезен при работе с механизмом RenderAction. RenderAction — это часть библиотеки MVCContrib, которая содержит расширения MVC Framework, не вошедшие в основной функционал. RenderAction позволяет представлению вывести в месте вызова результат выполнения действия. При таком применении результат типа ContentResult подходит более всего. Для упрощения контроллеры содержат специальный метод Content, который возвращает значение типа ContentResult.

EmptyResult

Последний из рассмотренных стандартных вариантов ActionResult — это EmptyResult. Этот механизм предназначен для того, чтобы в ответ на запрос не возвращать ничего. Переопределенный в EmptyResult метод ExecuteResult не содержит ни строчки кода.

Создание своей реализации ActionResult

Важной особенностью механизма ActionResult является то, что вы можете создать свой собственный вариант, который будет формировать результат в том виде, который вам нужен. Например, вы можете разработать класс, наследующий ActionResult, который будет возвращать клиентам результаты запроса в виде XML-разметки. Классическим примером создания своего варианта ActionResult является реализация класса, который на запрос пользователя создает ответ в виде RSS-ленты. Продемонстрируем реализацию такого класса, добавив к нашему контроллеру AdminController действие Rss, которое будет возвращать пользователю RSS-ленту со списком зарегистрированных пользователей.

Первым делом создадим класс RssResult, который наследует ActionResult, как показано в листинге 4.6.

Листинг 4.6. Класс RssResult

namespace MVCBookProject {

using System.Web.Mvc; using System.Xml;

using System.ServiceModel.Syndication;

public class RssResult : ActionResult {

public SyndicationFeed Feed { get; set; }

public RssResult(SyndicationFeed feed)

{

Feed = feed;

}

public override void ExecuteResult(ControllerContext context)

{

context.HttpContext.Response.ContentType =

"application/rss+xml";

Rss20FeedFormatter formatter = new Rss20FeedFormatter(Feed);

using (XmlWriter writer =

XmlWriter.Create(context.HttpContext.Response.Output))

{

if (writer != null)

formatter.WriteTo(writer);

}

}

}

}

Обратите внимание, для реализации своего варианта ActionResult в классе RssResult мы перегружаем метод ExecuteResult, который и выполняет всю необходимую логику по формированию того результата, который получит клиент в своем браузере в ответ на запрос.

Использование класса RssResult ничем не отличается от применения других вариантов классов ActionResult. Добавим действие Rss в контроллер AdminControiier так, как показано во фрагменте:

[AcceptVerbs(HttpVerbs.Get)]

public RssResult Rss()

{

MembershipProvider mp = Membership.Provider;

int userCount;

var users = mp.GetAllUsers(0, Int32.MaxValue, out userCount);

List<SyndicationItem> items = new List<SyndicationItem>();

if (userCount > 0)

{

string bodyTemplate = @"email: {0}, comment: {1},

last activity: {2}, is locked: {3}, is approved: {4}";

foreach (MembershipUser item in users)

{

string body = String.Format(bodyTemplate, item.Email,

item. Comment, item. LastActivityDate,

item.IsLockedOut, item.IsApproved);

items.Add(new SyndicationItem(item.UserName, body, null));

}

}

SyndicationFeed feed = new SyndicationFeed("Cписок пользователей",

"http://localhost/rss", Request.Url, items);

return new RssResult(feed);

}

Обратите внимание, что это действие возвращает результат в виде экземпляра класса RssResult, которому передается сгенерированный RSS-поток. После того как мы реализовали RssResult и действие Rss, можно попытаться запросить результат этого действия через браузер, перейдя по относительной ссылке /Admin/Rss. В итоге вы должны получить результат в виде RSS-потока, похожий на тот, который изображен на рис. 4.11.

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

Model Binding

После того как механизм MVC Framework получил запрос от клиента с набором некоторых параметров, произвел определение необходимого контроллера и действия, возникает задача сопоставления параметров запроса параметрам выбранного действия контроллера. Задача решается просто, когда параметров немного. В этом случае сопоставление параметров происходит по их наименованию: параметрам метода действия с определенным именем присваиваются значения параметров запроса с теми же именами. В качестве примера рассмотрим действие Update контроллера AdminController. Во фрагменте приведено определение метода с параметрами:

public ActionResult Update(Guid? userid, string email,

string comment, bool isApproved, bool isLockedOut)

Для этого действия подразумевается, что при его вызове будут переданы параметры с именами: userid, email, comment, isApproved, isLockedOut. Такие параметры передаются с запросом при отправлении формы с нашего представления Select. В следующем фрагменте рассмотрим основной HTML-код формы этого представления, который отображается в браузере пользователя:

<form action="/Admin/Update" method="post">

...

<input id="userId" name="userId" type="hidden"

value="a4530eee-8634-4258-ac00-0ea63f7cc783" />

...

<input id="email" name="email" type="text" value="vyunev@live.ru" />

...

<textarea cols="20" id="comment" name="comment" rows="2">

&lt;b&gt,Добрый день!&lt;/b&gt;

</textarea>

...

<input checked="checked" id="isApproved"

name="isApproved" type="checkbox" value="true" />

...

<input id="isLockedOut" name="isLockedOut"

type="checkbox" value="true" />

...

<input type="submit" value="Coxpaнить" />

</form>

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

Но что делать, когда форма содержит десятки вводимых полей? Неужели создавать десятки параметров у метода действия контроллера? Нет, MVC Framework содержит механизм, который позволяет избежать такого некрасивого шага, как многочисленные параметры метода. Такой механизм называется Model Binding (привязка модели). Чтобы продемонстрировать работу этого механизма, выполним ряд изменений в коде. Для начала определим комплексный тип, который будет содержать все необходимые данные, передаваемые в действие Update:

public class UserData

{

public Guid? UserId { get; set; }

public string Email { get; set; }

public string Comment { get; set; }

public bool IsApproved { get; set; }

public bool IsLockedOut { get; set; }

}

Обратите внимание, что для определения параметров мы используем свойства. Механизм Model Binding требует, чтобы использовались свойства, но не простые поля. Соответственно данному типу изменим определение метода Update:

public ActionResult Update(UserData userData)

{

if (!userData.UserId.HasValue)

throw new HttpException(404, "Пользователь не найден");

MembershipProvider mp = Membership.Provider;

MembershipUser user = mp.GetUser(userData.UserId, false);

user.Email = userData.Email;

user.Comment = userData.Comment;

user.IsApproved = userData.IsApproved;

if (user.IsLockedOut && !userData.IsLockedOut)

user.UnlockUser();

mp.UpdateUser(user);

return RedirectToAction("Index");

}

Теперь, чтобы механизм MVC Framework смог произвести сопоставление параметров с помощью встроенного механизма Model Binding, нам необходимо модифицировать код представления Select так, как показано в следующем фрагменте:

<% using (Html.BeginForm("Update", "Admin")) { %>

<%= Html.Hidden("userData.UserId", (Guid)user.ProviderUserKey)%>

<%= Html.AntiForgeryToken() %>

<fieldset>

<legend>Данные</legend>

<p>

<label for="email">Email</label>

<%=Html.TextBox("userData.Email", user.Email)%>

</p>

<p>

<label for="comment">Комментарий</label>

<%=Html.TextArea("userData.Comment", user.Comment)%>

</p>

<p>

<label for="isApproved">

<%=Html.CheckBox("userData.IsApproved", user.IsApproved)%>

подтвержден

</label>

</p>

<p>

<label for="isLockedOut">

<%=Html.CheckBox("userData.IsLockedOut", user.IsLockedOut)%>

заблокирован

</label>

</p>

</fieldset>

<input type="submit" value="Coxpaнить" />

<% } %>

Обратите внимание на то, что для всех полей формы мы использовали наименование вида userData.Свойство. Например, поле email стало полем с именем userData.Email. Такое именование позволяет классу DefaultModelBinder, механизму Model Binding по умолчанию, сопоставить множественные параметры формы комплексному типу UserData.

Примечание

Строго говоря, в данном случае вам необязательно указывать для элементов формы префикс userData. Так как в сопоставлении участвует только один параметр комплексного типа, то механизм DefaultModelBinder автоматически определит значения его свойств, предположив, что все элементы формы относятся к единственному параметру userData. Однако мы рекомендуем указывать подобный префикс в любом случае для повышения читаемости кода и возможности более простого расширения кода в будущем.

*********************************************

Важной частью MVC Framework является возможность определять собственные механизмы Model Binding. Эта возможность предоставляет разработчику определять то, как параметры запроса или значения формы поступают к действию контроллера для обработки. Для демонстрации работы этого механизма добавим к нашей модели UserData еще одно свойство CurrentMembershipUser, которое будет автоматически инициализироваться при сопоставлении параметров:

public class UserData {

public MembershipUser CurrentMembershipUser { get; set; }

}

Теперь реализуем наш собственный механизм Model Binding, создав класс UserDataBinder, реализующий интерфейс IModelBinder. Этот интерфейс содержит всего один метод BindModel, с помощью которого и выполняется вся работа по сопоставлению параметров:

public class UserDataBinder : IModelBinder

{

public object BindModel(ControllerContext controllerContext,

ModelBindingContext bindingContext)

{

UserData userData = new UserData();

userData.UserId = new

Guid(controllerContext.HttpContext.Request["UserId"]);

userData.Email = controllerContext.HttpContext.Request["Email"];

userData.Comment =

controllerContext.HttpContext.Request["Comment"];

userData.IsApproved =

controllerContext.HttpContext.Request["IsApproved"] != "false";

userData.IsLockedOut =

controllerContext.HttpContext.Request["IsLockedOut"] != "false";

MembershipProvider mp = Membership.Provider;

userData.CurrentMembershipUser =

mp.GetUser(userData.UserId, false);

return userData;

}

}

Обратите внимание на то, что при реализации своего механизма Model Binding мы сами указываем, какие параметры запроса и каким образом соответствуют ожидаемому комплексному типу вызываемого действия. Для того чтобы использовать эту реализацию интерфейса IModelBinder, мы должны зарегистрировать ее в Global.asax с помощью следующей конструкции:

protected void Application_Start()

{

...

ModelBinders.Binders.Add(typeof(UserData), new UserDataBinder());

}

Здесь мы добавляем в коллекцию еще один вариант Model Binder, который призван выполнять сопоставление типа UserData для всех действий любого контроллера в приложении.

Другим вариантом подключения нашего класса UserDataBinder может стать использование атрибута ModelBinderAttribute, в этом случае мы сможем явно указать, для какого конкретного параметра нужно использовать свой вариант Model Binder. ModelBinderAttribute позволяет более гибко управлять тем, когда и как применяются пользовательские элементы Model Binder, что не редко может быть полезным. При этом регистрировать в Global.asax UserDataBinder не потребуется. Используется атрибут ModelBinderAttribute следующим способом:

public ActionResult Update(

[ModelBinder(typeof(UserDataBinder))]  UserData userData)

Как вы видите, в данном случае атрибут использован для конкретного параметра одного-единственного действия.

В общем случае использование стандартного варианта Model Binding в виде класса DefaultModelBinder достаточно для осуществления сопоставления параметров запроса и параметров метода действия. Однако существует еще одна полезная функция механизма Model Binding в MVC Framework. Эта функция реализуется атрибутом BindAttribute и позволяет еще более гибко настраивать процесс сопоставления параметров по умолчанию. Атрибут BindAttribute имеет следующие параметры:

□ Prefix — позволяет переопределить префикс при сопоставлении по умолчанию;

□ Include — позволяет определить список допустимых параметров, которые будут участвовать в сопоставлении, остальные параметры, не входящие в этот список, рассматриваться не будут;

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

Использование параметра Prefix позволяет применять в представлении префикс для элементов формы, отличный от имени параметра метода действия. Например, вместо префикса userData в рассмотренном ранее примере, мы могли бы использовать сокращенный префикс ud, определив все элементы управления формы в подобном виде:

<%= Html.Hidden("ud.UserId", (Guid)user.ProviderUserKey)%>

Чтобы механизм Model Binder по умолчанию узнал про наш новый префикс, необходимо задать атрибут BindAttribute в требуемом месте при определении параметров метода действия:

public ActionResult Update([Bind(Prefix = "ud")] UserData userData)

Параметры Include и Exclude атрибута BindAttribute могут быть полезны в тех случаях, когда необходимо избежать автоматического сопоставления в комплексном типе для каких-то определенных свойств. Это может потребоваться для обеспечения безопасности или по каким-то другим соображениям. Например, чтобы запретить сопоставление свойства IsLockedOut, мы можем указать атрибут BindAttribute следующим образом:

public ActionResult Update(

[Bind(Exclude = "IsLockedOut")] UserData userData)

Иногда требуется задать определенный список разрешенных для сопоставления параметров. Для этого используется параметр Include, которому можно задать список разрешенных для сопоставления свойств. В следующем примере мы разрешаем для сопоставления только два свойства: Userid и Email:

public ActionResult Update(

[Bind(Include = "UserId, Email")] UserData userData)

Механизм сопоставления комплексных параметров форм с параметрами методов действий в MVC Framework значительно упрощается с помощью встроенного средства DefaultModelBinder. Этот механизм может гибко настраиваться с помощью атрибута BindAttribute, который позволяет задавать списки допустимых и недопустимых для сопоставления свойств и, вдобавок к этому, переопределять префикс, используемый в представлении. Если же разработчику недостаточно функционала механизма Model Binding по умолчанию, он волен переопределить этот механизм своей реализацией и использовать его как глобально во всем приложении, так и определяя его для конкретного параметра определенного действия.

Советы по использованию контроллеров

Атрибуты ActionNameSelectorAttribute и ActionNameAttribute

В механизме MVC существует множество полезных функций. Одна из них — это атрибут ActionNameAttribute, являющийся реализацией атрибута ActionNameSelectorAttribute — механизма MVC Framework, который позволяет ограничить выбор методов класса контроллера при определении нужного.

Атрибут ActionNameSelectorAttribute содержит всего один метод IsValidName со следующим определением:

public abstract bool IsValidName(ControllerContext controllerContext,

string actionName, MethodInfo methodInfo);

При поиске необходимого для выполнения действия механизм MVC Framework, кроме всего прочего, проверит все действия на наличие атрибута, реализующего ActionNameSelectorAttribute. В случае, когда такой атрибут найден, у него вызывается метод IsValidName для проверки на соответствие действия требуемому имени.

Единственная реализация ActionNameSelectorAttribute, существующая в MVC Framework, — это атрибут ActionNameAttribute, который призван предоставить возможность создания псевдонимов для методов действий. Рассмотрим следующий фрагмент кода:

[ActionName("UserList")]

public ActionResult GetUserListFromCache()

Здесь методу GetuserListFromCache, который представляет собой действие контроллера, присваивается укороченный псевдоним userList. После этого в ответ на запрос действия UserList контроллером может быть вызван метод GetuserListFromCache.

Наследование контроллеров

При работе с контроллерами в MVC Framework полезной практикой является механизм наследования контроллеров. Так как контроллеры представляют собой классы, преимущества наследования контроллеров схожи с преимуществами наследования классов в C#. Основным таким преимуществом является возможность создания базового набора правил для некоторого количества контроллеров. Для этого в MVC Framework можно определить контроллер, который будет называться базовым, и наследовать все остальные контроллеры от него.

Далее перечислены примеры возможных функций базовых контроллеров:

□ хранение и предоставление информации о текущем пользователе и его правах;

□ предоставление информации о базовых настройках приложения, которые могут поставляться, например, из web.config;

□ экземпляры хранилищ кода для работы с разнообразным функционалом: от пользователей до специфических данных приложения;

□ вспомогательные статические или другие методы утилитарного характера;

□ определение набора атрибутов, которые будут наследовать потомки базового контроллера.

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

Листинг 4.7. Базовый контроллер

[HandleError(View = "AdminError")]

[GZipCompress]

public class BaseController : Controller

{

public NameValueCollection Settings

{

get

{

return ConfigurationManager.AppSettings;

}

}

public string UserNotFoundMessage

{

get

{

return Settings["userNotFoundMessage"];

}

}

public readonly MembershipProvider MP = Membership.Provider;

public virtual ActionResult Index()

{

return View();

}

public static MembershipUser GetUser(string userName)

{

MembershipProvider mp = Membership.Provider;

return mp.GetUser(userName, false);

}

public static MembershipUser GetUser(Guid userId)

{

MembershipProvider mp = Membership.Provider;

return mp.GetUser(userId, false);

}

}

Базовый контроллер из листинга 4.7 обладает следующими свойствами:

□ определяет для контроллера действие по умолчанию Index;

□ определяет атрибуты по умолчанию для обработки ошибок и сжатия результатов через GZip;

□ определяет обертку Settings над секцией настроек appSettings файла web.config, для более прозрачного доступа к настройкам;

□ прямо определяет UserNotFoundMessage, одну из настроек секции appSettings для быстрого к ней доступа;

□ определяет упрощенный доступ к объекту Membership.Provider;

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

Чтобы наделить этими свойствами любой контроллер, необходимо наследовать его от базового. Модифицируем контроллер AdminController согласно новым правилам так, как показано во фрагменте:

public class AdminController : BaseController {

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Users = "Admin")]

public override ActionResult Index()

{

int userCount;

var users = MP.GetAllUsers(0, Int32.MaxValue, out userCount);

ViewData.Model = users;

return View();

}

[AcceptVerbs(HttpVerbs.Get)]

[Authorize(Users = "Admin")]

public ActionResult Select(Guid? userId)

{

if (!userId.HasValue)

throw new HttpException(404, UserNotFoundMessage);

return View("Select", "Site", GetUser(userId.Value));

}

}

Обратите внимание, класс контроллера наследует BaseController, в связи с этим действие Index переопределяется с помощью ключевого слова override. Кроме того, в Index используется новое свойство mp, определенное в базовом контроллере. В другом действии, Select, используются два других функционала базового контроллера: свойство UserNotFoundMessage и статический метод GetUser.

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

Асинхронное выполнение при работе с контроллерами

При создании веб-приложений часто может возникнуть проблема с обработкой данных, которая отнимает большие ресурсы и машинное время. Механизм ASP.NET имеет ограниченное количество потоков, которые предназначены для обработки пользовательских запросов, полученных от сервера IIS. Проблема состоит в том, что если один из запросов предполагает продолжительную работу с привлечением больших ресурсов, то такой запрос может уменьшить пропускную способность сайта. В случаях, когда таких запросов много, их выполнение может вообще заблокировать доступ пользователей к ресурсу, т. к. все рабочие потоки ASP.NET будут заняты, простаивая в ожидании того, когда завершится выполнение тяжелого запроса к базе данных или сложное вычисление.

Выходом из такой ситуации может служить асинхронное выполнение запросов. При асинхронном выполнении тяжелая задача поручается для выполнения отдельному специально созданному потоку, а основной поток ASP.NET освобождается для обработки других пользовательских запросов. Для реализации такого функционала разработчиками MVC Framework был создан специальный механизм AsyncController, который хоть и не вошел в MVC Framework, но доступен в особой библиотеке MVC Framework Futures, которая представлена файлом Microsoft.Web.Mvc.dll.

Примечание

Саму библиотеку и документацию к ней на английском языке можно скачать с официальной страницы ASP.NET MVC на сайте Codeplex по следующему адресу: http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24471

******************************

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

routes.MapAsyncRoute(

"Default",

"{controller}/{action}/{id}",

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

);

Обратите внимание на то, что вызов routes.MapRoute заменен на routes.MapAsyncRoute, это необходимо, чтобы механизм MVC мог обрабатывать как асинхронные, так и синхронные контроллеры. После изменений в регистрации маршрутов нет нужды в других изменениях, чтобы специально отслеживать синхронные контроллеры, поскольку механизм MapAsyncRoute регистрирует маршруты как для асинхронных, так и синхронных контроллеров.

После изменения регистрации маршрутов следует изменить обработчики для *.mvc, определенные ранее в web.config, следующим образом в разделах httpHandlers и handlers:

<add verb="*" path="*.mvc" validate="false"

type="System.Web.Mvc.MvcHttpHandler,

System.Web.Mvc, Version=1.0.0.0,

Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

<add name="MvcHttpHandler" preCondition="integratedMode"

verb="*" path="*.mvc" type="System.Web.Mvc.MvcHttpHandler, System.Web.Mvc,

Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Эти определения обработчиков необходимо заменить на следующие:

<add verb="*" path="*.mvc" validate="false"

type="Microsoft.Web.Mvc.MvcHttpAsyncHandler, Microsoft.Web.Mvc"/>

<add name="MvcHttpHandler" preCondition="integratedMode"

verb="*" path="*.mvc" type="Microsoft.Web.Mvc.MvcHttpAsyncHandler,

Microsoft.Web.Mvc"/>

После всех изменений можно приступать к работе с асинхронными контроллерами. Для того чтобы класс контроллера стал асинхронным, необходимо наследовать его от класса AsyncController:

public class SomeAsyncController : AsyncController

{

...

}

После этого конструктор по умолчанию, унаследованный от AsyncController, определит новый вариант ActionInvoker в виде экземпляра класса AsyncControllerActionInvoker для того, чтобы выполнять асинхронные действия. Для реализации асинхронных действий механизм AsyncController предлагает три паттерна, которые вы вольны использовать по отдельности либо смешивать их друг с другом: IAsyncResult, Event, Delegate.

Паттерн IAsyncResult

Паттерн IAsyncResult предполагает, что разработчик сам создаст асинхронную операцию. Согласно этому паттерну, вместо одного метода действия с именем XXX создаются два метода, BeginXXX и EndXXX, со следующим определением параметров:

public IAsyncResult BeginXXX(Guid? userId, AsyncCallback callback, object state);

public ActionResult EndXXX(IAsyncResult asyncResult);

Этот паттерн работает следующим образом:

1. MVC принимает запрос на выполнение действия xxx.

2. Механизмы MVC и AsyncController вызовут BeginXXX точно так же, как и любое другое синхронное действие.

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

4. После выполнения асинхронной операции будет вызван второй метод Endxxx, которому будет передан результат выполнения Beginxxx в виде экземпляра IAsyncResult.

5. Метод Beginxxx, используя данные, полученные от Beginxxx, формирует обычный для всех действий результат в виде ActionResult или его производных.

Паттерн Event

Согласно этому паттерну, метод действия разделяется на два метода: запуска и завершения:

public void XXX(Guid? userId);

public ActionResult XXXCompleted(...);

Метод xxx соответствует обычному синхронному действию и вызывается стандартно. Полный механизм работы данного паттерна состоит из следующих действий:

1. MVC принимает запрос на выполнение действия xxx.

2. Механизмы MVC и AsyncController вызовут XXX точно так же, как и любое другое синхронное действие.

3. Разработчик определяет внутри метода xxx асинхронную операцию, после запуска которой метод завершает свое выполнение.

4. Чтобы механизм асинхронных контроллеров мог определить, когда следует вызвать XXXCompleted, разработчик должен воспользоваться свойством AsyncManager.OutstandingOperations, которое является стандартным для класса контроллера AsyncController.

5. Разработчик инкрементирует AsyncManager.OutstandingOperations при создании каждого асинхронного процесса и заботится о том, чтобы по завершению процесса свойство AsyncManager.OutstandingOperations было декрементировано.

6. Механизм AcyncControllerActionInvoker следит за свойством AsyncManager.OutstandingOperations и вызывает XXXCompleted, когда это свойство обнулится, что означает завершение работы всех асинхронных процессов.

7. Параметры для XXXCompleted определяет разработчик. Для того чтобы AcyncControllerActionInvoker мог правильно выполнить XXXCompleted и передать необходимые параметры, разработчик заполняет специальную структуру AsyncManager.Parameters, которая является частью класса AsyncController. Структура AsyncManager.Parameters заполняется при работе метода xxx.

8. После завершения работы XXX механизм AcyncControllerActionInvoker вызывает метод XXXCompleted с набором параметров на базе AsyncManager.Parameters.

9. Используя переданные параметры, метод XXXCompleted возвращает стандартный результат в виде ActionResult или его производных.

Следующий фрагмент кода демонстрирует реализацию паттерна Event:

public void SelectUser(Guid? userId)

{

AsyncManager.Parameters["userData''] = new UserData();

AsyncManager.OutstandingOperations.Increment();

ThreadPool.QueueUserWorkItem(o =>

{

Thread.Sleep(2000);

AsyncManager.OutstandingOperations.Decrement();

}, null);

}

public ActionResult SelectUserCompleted(UserData userData)

{

...

}

Чтобы упростить процесс, существует альтернатива прямому инкрементированию и декрементированию. С помощью стандартной части AsyncController метода AsyncManager.RegisterTask можно использовать связку из паттернов IAsyncResult и Event. Рассмотрим на примере:

public void XXX(Guid? userId)

{

AsyncManager.RegisterTask(

callback => BeginXXX(userId, callback, null),

asyncResult =>

{

UserData userData = EndXXX(asyncResult);

AsyncManager.Parameters["userData"] = userData;

}

);

}

public ActionResult XXXCompleted(UserData userData)

{

// ...

}

Во фрагменте кода используется паттерн Event, согласно которому создается два метода: xxx и xxxCompleted. Метод xxx регистрирует асинхронную задачу с помощью механизма AsyncManager.RegisterTask, который принимает два параметра: анонимные функции, осуществляющие логику паттерна IAsyncResult. Первая функция вызывает метод Beginxxx, который выполняет некую асинхронную операцию. Вторая анонимная функция выполняется тогда, когда асинхронная операция заканчивается и ей передаются результаты вызова Beginxxx. Задача второй анонимной функции состоит в том, чтобы, используя метод Endxxx паттерна IAsyncResult, получить значения параметров для метода XXXCompleted.

Преимущество данной связки паттернов состоит в том, что разработчику предоставляется возможность создавать несколько следующих подряд вызовов механизма AsyncManager.RegisterTask, которые выполняют разные асинхронные операции и формируют результаты разных параметров для метода XXXCompleted. Так как механизм AsyncManager.RegisterTask самостоятельно отслеживает инкремент и декремент свойства AsyncManager.OutstandingOperations, разработчику предлагается более безопасный и простой механизм создания нескольких асинхронных операций в одном запросе.

Паттерн Delegate

Этот паттерн похож на паттерн Event с одним существенным отличием: отсутствует метод xxxComplete. Вместо этого метод xxx сам занимается возвращением результата ActionResult на основании данных, полученных от асинхронных операций. Так выглядит определение метода действия при использовании паттерна Delegate:

public Func<ActionResult> Foo(Guid? userId)

Для демонстрации реализации данного паттерна перепишем пример паттерна Event по-другому:

public Func<ActionResult> XXX(Guid userId)

{

UserData userData = new UserData();

AsyncManager.RegisterTask(

callback => BeginXXX(userId, callback, null),

asyncResult =>

{

userData = EndXXX(asyncResult);

}

);

return () => {

ViewData["userData"] = userData;

return View() ;

};

}

Главное отличие реализации паттерна Delegate в приведенном фрагменте от паттерна Event состоит в том, что для возвращения результата выполнения действия используется не ActionResult, а Func<ActionResult>, который представляет собой анонимную функцию, возвращающую результат в виде ActionResult. По сравнению с паттерном Event данный паттерн имеет упрощенный единый механизм, не разделенный на несколько методов, и максимально напоминает работу действий в синхронных контроллерах. При использовании этого паттерна у разработчика нет необходимости заботиться ни об обработке AsyncManager.OutstandingOperations, ни о заполнении AsyncManager.Parameters.

Дополнительные сведения об асинхронных контроллерах

Для асинхронных операций важно понятие времени исполнения запроса, поэтому в стандартный механизм класса AsyncController входит свойство AsyncManager.Timeout, которое позволяет задавать максимальное время ожидания результата выполнения асинхронного действия. В случае, когда действие выполняется дольше, чем определено в AsyncManager.Timeout механизмом, будет вызвано исключение TimeoutException. Для более гибкого управления максимальным периодом ожидания ответа от действия механизм асинхронных контроллеров предлагает два атрибута: AsyncTimeoutAttribute и NoAsyncTimeoutAttribute. Первый устанавливает время ожидания для конкретного действия или контроллера, второй указывает, что ожидания ответа не должно вызвать исключения и ожидать ответа от асинхронного действия требуется без ограничения по времени.

Одним из ограничений механизма асинхронных контроллеров является ограничение на именование методов действий. Вы не можете называть методы действий с префиксами Begin, End и суффиксом Completed. Это ограничение призвано предотвратить прямой вызов методов типа BeginXXX, EndXXX или XXXCompleted вместо вызова XXX. Тем не менее вы можете воспользоваться атрибутом ActionNameAttribute для того, чтобы задать необходимый псевдоним методу действия. Следующий фрагмент демонстрирует это:

[ActionName("BeginProcess")]

public ActionResult DoProcess();

Еще одним требованием механизма асинхронных контроллеров является исключение Default.aspx из корня проекта в случае, когда запросы к корневому ресурсу будут асинхронными. Default.aspx, включенный в стандартный проект MVC Framework, может работать только с синхронными запросами.

Неизвестные действия и метод HandleUnknownAction

Во время обработки клиентских запросов весьма распространенной ситуацией является невозможность определить действие, которое необходимо вызвать в ответ на запрос. Класс Controller, базовый класс контроллеров MVC Framework, содержит виртуальный метод HandleUnknownAction, который предназначен для обработки подобных ситуаций. Метод HandleUnknownAction имеет следующее определение:

protected virtual void HandleUnknownAction(string actionName)

{

throw new HttpException(404,

String.Format(CultureInfo.CurrentUICulture,

MvcResources.Controller_UnknownAction,

actionName, GetType().FullName));

}

Как можно понять из определения, если разработчик не переопределит действие метода HandleUnknownAction, то по умолчанию, когда MVC Framework не сможет найти действие для выполнения клиентского запроса, будет вызвано исключение, которое приведет к ответу пользователю в виде 404 HTTP-ошибки.

Разработчик может легко переопределить метод HandleUnknownAction в своем контроллере для того, чтобы иметь возможность обрабатывать ситуации, когда запрос пользователя пытается вызвать некое действие, которое недоступно для исполнения. В таких случаях, имеет смысл вносить подобные запросы в системный лог для последующего анализа на предмет безопасности или наличие ошибок в сформированных ссылках на страницах проекта разработчика. Кроме того, бывают ситуации, когда существует возможность вызвать "правильный" метод, вместо запрошенного пользователем "неправильного". Это также можно реализовать с помощью переопределения метода HandleUnknownAction.

ГЛАВА 5

Представление и интерфейс приложения

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

Стандартный механизм представлений на базе WebForms

Создатели MVC Framework пошли по пути максимального использования существующей инфраструктуры ASP.NET. За счет этого разработчики, знакомые с WebForms, в ASP.NET могут использовать известные концепции пользовательских элементов управления и мастерских страниц для формирования шаблонов оформления приложения. В то же время подход к созданию страниц существенно изменился, о чем подробно было рассказано в главах 1 и 2 этой книги.

До того как рассматривать непосредственно создание представлений, рассмотрим необходимые компоненты инфраструктуры, обеспечивающие работу представлений — использование code-behind-файлов, мастерские страницы, механизм передачи данных между контроллером и представлением через коллекцию viewData и строгая типизация представлений.

Code-behind-файлы

Модель использования code-behind-файлов в WebForms является основой разделения логики представления, выполненной в файле разметки ASPX, и бизнес-логики самой страницы, выполненной в файле исходного кода.

Напомним, что непосредственно в файле разметки страницы указана ссылка на code-behind-файл страницы и класс, определенный в code-behind-файле, которому наследует страница:

%@Page Language="C#" Inherits="MyApp.Pg" CodeBehind="Pg.aspx.cs"%

Класс, определенный в code-behind-файле, служит "прослойкой" между страницей и классом System.Web.UI.Page, базовым для всех страниц WebForms, и отвечает за обработку событий жизненного цикла страницы. В случае, если дополнительная обработка событий не является необходимой, файл code-behind может быть смело удален, а страница может непосредственно наследовать классу System.Web.UI.Page:

<% @Page Language="C#" Inherits="System.Web.UI.Page" %>

В MVC Framework не используется жизненный цикл страниц ASP.NET, поэтому для представлений применяется аналогичный подход с исключением code-behind-файла, и страницы наследуют непосредственно классу System.Web.Mvc.ViewPage или обобщающему классу System.Web.Mvc.ViewPage<T>, используемому для строгой типизации представлений, описанному далее.

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

Мастерские страницы и элементы управления

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

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

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

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

<asp:ContentPlaceHolder ID="ContentPageId" runat="server" />

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

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

<asp:Content ID="myPage" ContentPlaceHolderID="ContentPageId" runat="server">

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

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

<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

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

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>

<asp:ContentPlaceHolder ID="TitleContent" runat="server" />

</title>

<link href="../../Content/Site.css" rel="stylesheet" type="text/css" />

</head>

<body>

<div class="page">

<div id="header">

<div id="title">

<h1>

Northwind

</h1>

</div>

<div id="logindisplay">

<% Html.RenderPartial("LogOnUserControl"); %> </div>

<div id="menucontainer">

<ul id="menu">

<li>

<%= Html.ActionLink("Домашняя", "Index",

"Home")%>

</li>

<li>

<%= Html.ActionLink("O сайте", "About",

"Home")%>

</li>

</ul>

</div>

</div>

<div id="main">

<asp:ContentPlaceHolder ID="MainContent" runat="server" /> <div id="footer">

</div>

</div>

</div>

</body>

</html>

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

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="aboutTitle" ContentPlaceHolderID="TitleContent" runat="server">

о проекте

</asp:Content>

<asp:Content ID="aboutContent" ContentPlaceHolderID="MainContent" runat="server">

<h2>

О проекте

</h2>

<p>

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

</p>

</asp:Content>

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

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

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

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

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

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<%

if (Request.IsAuthenticated) {

%>

Добро пожаловать <b><%= Html.Encode(Page.User.Identity.Name)

%></b>!

[ <%= Html.ActionLink("Выход", "LogOff", "Account") %> ]

<%

}

else {

%>

[ <%= Html.ActionLink("Вход", "LogOn", "Account") %> ]

<%

}

%>

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

Файлы представлений в структуре проекта

В главе 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. Возможно, что вам будет удобнее создать иную структуру директорий и группировать статические файлы не по принадлежности к представлениям, а по расположению звезд на небосклоне или какой-либо другой логике.

Данные для отображения и ViewData

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

ViewData — это класс типа viewDataDictionary, из названия типа которого очевидно, что ViewData представляет собой коллекцию типа ключ-значения, называемую словарем.

public class ViewDataDictionary : IDictionary<string, object> {}

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

public ActionResult ViewDataDemo()

{

ViewData.Add("Hello", "World");

ViewData["Date"] = DateTime.Now;

return View();

}

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

<p><%= ((DateTime)ViewData["Date"]).ToLongTimeString() %></p>

Строгая типизация данных представления

Работа с произвольным набором элементов удобна, когда набор данных, отображаемых представлением, меняется в процессе развития проекта. Однако в случаях, когда все данные представления могут быть описаны одним классом, значительно удобнее использовать строго типизированные представления. Для этого коллекция ViewData предоставляет свойство ViewData.Model и возможность строгой типизации представления путем наследования самого класса представления от класса ViewPage<T>. В листинге 5.4 представлена разметка строго типизированного представления.

Листинг 5.4. Представление ViewDataModelStronglyTyped.aspx

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<MvcViewsDemo.Models.Customer>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">

ViewDataModelStronglyTyped

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

<h2>

ViewDataModelStronglyTyped

</h2>

<fieldset>

<legend>Fields</legend>

<p>

CompanyName:

<%= Html.Encode(Model.CompanyName) %>

</p>

<p>

ContactName:

<%= Html.Encode(Model.ContactName) %>

</p>

<p>

ContactTitle:

<%= Html.Encode(Model.ContactTitle) %>

</p>

<p>

Address:

<%= Html.Encode(Model.Address) %>

</p>

</fieldset>

</asp:Content>

С точки зрения контроллера, для работы со строго типизированным представлением достаточно присвоить объект свойству ViewData.Model либо передать объект в качестве параметра методу View ().

public ActionResult ViewDataModelStronglyTyped()

{

NorthwindDatabase db = new NorthwindDatabase();

return View(db.GetCustomers().First());

}

В случае нестрого типизированного представления объект также может быть передан в свойство ViewData.Model, однако это не имеет практической пользы, поскольку на стороне представления все равно придется выполнять приведение типов для свойств этого объекта.

Преимущества строго типизированного представления очевидны — поддержка подсказки IntelliSense при разработке представлений в Visual Studio, возможность генерации заготовок представлений средствами Visual Studio, как это было выполнено для представления, приведенного в листинге 5.4.

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

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

Поиск элементов в коллекции ViewData

Легко представить себе ситуацию, в которой на стороне представления заранее не определено, где находятся данные — в коллекции viewData или же в свойствах объекта viewData.Model. Для поиска этого элемента доступен специальный метод viewData.Eval(), осуществляющий поиск в коллекции элементов и в свойствах объекта модели, при этом поддерживается синтаксис точки (.) между именами свойств объектов.

Например, в представлении используется метод viewData.Eval("customer. lastname"), тогда будет выполнен поиск элемента по описанному далее алгоритму.

1. Будет проверено наличие значения ViewData["customer. lastname"].

2. Если значение отсутствует для приведенного ранее элемента коллекции, то будет осуществлен поиск элемента ViewData["customer"] .

3. В случае если элемент найдет по ключу "customer", то будет осуществлена попытка получить значение ViewData["customer"].lastname, если же такого свойства у объекта, содержащегося под ключом "customer", найдено не будет, будет осуществлена попытка найти элемент вложенной коллекции ViewData["customer"]["lastname"].

4. В случае провала предыдущих попыток поиска будут проверены свойства объекта Model: ViewData.Model.customer.lastname и ViewData.Model.customer["lastname"].

Описанный ранее метод поиска приводит к нескольким выводам — при поиске элементы коллекции viewData имеют приоритет над свойствами объекта, передаваемого через свойство в Model, поэтому следует не допускать совпадения именований свойств объекта, передаваемого через Model и элементов коллекции ViewData.

Использование метода viewData.Eval несет в себе также и возможность передавать строку для форматирования вывода данных.

<%= ViewData.Eval("customer.regDate", "Клиент с {0:yyyy} года.") %>

Метод viewData используется внутренней инфраструктурой MVC Framework для связывания данных с полями ввода и вывода информации о проверке корректности данных, о чем подробнее будет рассказано далее в этой главе вразд. "Валидация данных форм”.

Генерация разметки представлением

Для создания логики генерации представления в MVC Framework используются несколько подходов.

□ Вложенный управляющий код. Логика отображения данных описывается непосредственно внутри файла разметки ASPX с использованием стандартного синтаксиса <% %> для управляющих конструкций и синтаксиса <%= %> для вывода строковых значений непосредственно в результирующий код разметки.

□ Вспомогательные методы для генерации разметки. Вспомогательные методы позволяют многократно использовать фрагменты логики генерации представления и представляют собой вызовы некоторых методов, возвращающих строки. В библиотеке MVC Framework существует большой набор готовых вспомогательных методов, представленных как методы-расширения для классов Html, Url, Ajax, однако в качестве вспомогательного метода может быть использован любой метод, возвращающий строковое значение.

□ Серверные элементы управления. Несмотря на отсутствие возможности использования событийной модели, серверные элементы управления ASP.NET по-прежнему могут быть использованы для декларативного отображения данных.

Примечание

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

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

*****************************************

Вложенный управляющий код

Рассмотрим простейший пример — в представлении необходимо вывести таблицу, содержащую набор записей, переданных контроллером через коллекцию viewData. В качестве источника данных используется ставшая уже стандартом де-факто для примеров база данных Northwind, для доступа к которой используется LINQ для SQL, подробно описанный в главе 3.

В примере мы будем работать с классом Customer, упрощенное представление которого приведено в листинге 5.5.

Листинг 5.5. Класс Customer

public class Customer {

public string CustomerlD {get; set;}

public string CompanyName {get; set;}

public string ContactName {get; set;}

public string ContactTitle {get; set;}

public string Address {get; set;}

public string City {get; set;}

public string Region {get; set;}

public string PostalCode {get; set;}

public string Country {get; set;}

public string Phone {get; set;}

public string Fax {get; set;}

public EntitySet<CustomerCustomerDemo>

CustomerCustomerDemos {get; set;}

public EntitySet<Order> Orders {get; set;}

}

Данные передаются контроллером HomeController представлению Index.aspx через коллекцию viewData в качестве перечислимой коллекции, возвращаемой вспомогательным методом-оберткой над стандартными классами, созданными LINQ для SQL. Код, отвечающий непосредственно за получение данных, не представляет интереса для целей этого примера и не приводится.

public ActionResult Index()

{

NorthwindDatabase db = new NorthwindDatabase();

ViewData["Message"] = "Список сотрудников";

ViewData["Customers"] =

db.GetCustomers(c => c.CompanyName, 5);

return View () ;

}

В результате представлению Index.aspx будет передана коллекция объектов типа Customer, которую требуется представить в виде таблицы. С использованием управляющего кода разметка представления может выглядеть так, как показано в листинге 5.6.

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

<%@ Page Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<%@ Import Namespace="MvcViewsDemo.Models" %>

<asp:Content ID="indexTitle"

ContentPlaceHolderID="TitleContent" runat="server">

Домашняя страница

</asp:Content>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">

<h2>

<%= Html.Encode(ViewData ["Message"]) %></h2>

<table>

<thead>

<tr>

<th>

Название компании

</th>

<th>

Контактное лицо

</th>

</tr>

</thead>

<% foreach

(Customer c in (IEnumerable<Customer>)ViewData["Customers"]

) { %>

<tr>

<td>

<%= c.CompanyName %>

</td>

<td>

<%= c.ContactName %>

</td>

</tr>

<% } %>

</table>

</asp:Content>

В результате выполнения примера приведенное ранее представление будет отображено в виде, показанном на рис. 5.1.

В тексте листинга 5.6 управляющие конструкции выделены полужирным шрифтом.

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

<%= значение %>

Конструкция вида <%= значение %> используется для вывода значений в результирующий код HTML-разметки. Тип значения может быть любым, который может быть приведен к строке. Значение будет выведено именно в том месте разметки, в котором оно размещено.

<% управляющая конструкция %>

Управляющие инструкции позволяют проверять выполнение некоторых условий для вывода той или иной HTML-разметки (условия) либо многократно повторять фрагменты HTML-разметки (циклы).

Оформляются управляющие конструкции по приведенному далее шаблону.

<% инструкция (условия) { %>

Произвольный HTML-код, который может

перемежаться другими

управляющими инструкциями

<% } %>

Пример использования цикла приведен в листинге 5.6, применение условий выглядит аналогично:

<% if (Request.IsAuthenticated) { %>

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

<b><%= Html.Encode(Page.User.Identity.Name) %></b>!

[ <%= Html.ActionLink("Выход", "LogOff", "Account") %> ]

<%

} else {

%>

[ <%= Html.ActionLink("Вход", "LogOn", "Account") %> ]

<% } %>

Вспомогательные методы

Вспомогательные методы класса HtmlHelper, доступного как свойство Html для представлений и частичных представлений, уже неоднократно встречались в коде ранее. Теперь пришла пора рассмотреть подробнее, какую функциональность они несут и какие задачи решают.

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

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

Таблица 5.1. Вспомогательные методы класса HtmlHelper

Большая часть вспомогательных методов реализованы как методы-расширения C# 3.0 для класса HtmlHelper (статические методы, определенные вне класса HtmlHelper). Такой подход был избран для того, чтобы разработчики легко могли расширять набор вспомогательных методов в собственных классах и не перегружать сам класс HtmlHelper.

Далее рассмотрено применение каждого из методов, описанных в табл. 5.1. Методы сгруппированы по сходству решаемых задач.

Кодирование текста и атрибутов

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

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

Для кодирования предназначены два вспомогательных метода — Html.AttributeEncode() и Html.Encode().

Пример использования Html.AttributeEncode():

<div someattr="<%= Html.AttributeEncode("<b>Teкст</b>")"></div>

Результирующая разметка:

<div someattr="&lt;b>Teкст&lt;/b>"></div>

Пример использования Html.Encode():

<div><%= Html.Encode("<b>Текст</b>")</div>

Результирующая разметка:

<div>&lt;b&gt;TeKCT&lt;/b&gt;"</div>

Примечание

Важно отметить, что методы Html.AttributeEncode() и Html.Encode() не заменяют символ апострофа (') на соответствующий HTML-код, поскольку не рекомендуется использовать апострофы для атрибутов тегов на HTML-страницах, хотя это и допустимо с точки зрения HTML-стандарта.

**********************************

Гиперссылки на действия контроллеров

Для создания гиперссылок на действия контроллеров используются два основных вспомогательных метода — Html.ActionLink() и Html.RouteLink().

Html.ActionLink()

Метод Html.ActionLink() применяется для ссылок с использованием строковых значений. Например, для ссылки на действие Index, контроллера Home, именуемой "Главная страница", метод используется следующим образом:

Hnml.ActionLink("Главная страница", "Index", "Home")

Результирующая разметка:

<а href="/Home/Index">Главная страница</а>

Для того чтобы передать параметры в строке запроса, методу ActionLink() необходимо передать анонимный объект, содержащий значения параметров в свойствах объекта. При генерации гиперссылки будут учтены параметры маршрутов, зарегистрированных для приложения (подробная информация о маршрутизации приведена в главе 6).

Так, например, если для приложения определен только маршрут

{controller}/{action}/{id}, то следующий вызов метода ActionLink()

Html.ActionLink("Ссылка", "Data", "Home", new { id = 1, ord = 2 })

приведет к генерации такой ссылки:

<a href="/Home/Data/1?ord=2">Ссылка</a>

Если же среди маршрутов определен, например, и такой {controller}/{action}/{id}/{ord}, то будет сгенерирована следующая ссылка:

<a href="/Home/Data/1/2">Сcылка</a>

Для создания абсолютной ссылки, либо ссылки с дополнительными параметрами, такими как протокол, якорь, также можно воспользоваться методом ActionLink().

Html.ActionLink("Сайт microsoft.com", "Express", "VStudio",

"http", "microsoft.com", "download", new {}, null);

В результате будет создана следующая ссылка:

<a href="http://microsoft.com/VStudio/Express#download">

Сайт microsoft.com</a>

Html. RouteLink()

Метод Html.RouteLink() используется для создания ссылок на основании определенных для приложения маршрутов, о которых подробнее можно узнать в следующей главе. Так, например, можно сослаться на определенный именованный маршрут, передав параметры в виде анонимного объекта.

Html.RouteLink("Ссылка", "MyRoute",

new { action = "hello", id = 1 });

В результате будет создана следующая ссылка, при условии, что маршрут SomeRoute определен как mycontroller/{action}/sometext/{id}.

<a href="/mycontroller/hello/sometext/1">Сcылка</a>

Элементы управления HTML-страницы

Большая часть вспомогательных методов, приведенных в табл. 5.1, связаны с созданием HTML-разметки для элементов ввода данных HTML-форм. В этой части главы мы рассмотрим их применение.

HTML-форма

Для того чтобы данные, введенные пользователем в элементы управления, были корректно отправлены на сервер и обработаны ожидающим этих данных действием контроллера, необходимо создать тег <form>, для этого существует вспомогательный метод Html.BeginForm(действие контроллера, имя контроллера). Если при вызове метода не указаны параметры, атрибут action тега <form> будет заполнен текущим URL.

<% using(Html.BeginForm("About", "Home")){ %>

<% } %>

В примере используется синтаксис using(){}. Дело в том, что метод Html.BeginForm() возвращает объект, реализующий интерфейс IDisposable. Метод Dispose() этого объекта определен таким образом, чтобы выводить закрывающий тег формы </form>. Вместо синтаксиса using(){} можно воспользоваться вспомогательным методом Html. EndForm().

<% Html.BeginForm("About", "Home"); %>

<% Html.EndForm (); %>

Синтаксис using(){} удобнее при наличии нескольких независимых форм на странице — в этом случае формы будут выглядеть визуально обособленно.

При отображении представления будет создана соответствующая разметка для тега <form>.

<form action="/Home/About" method="post">

</form>

В случае необходимости задать дополнительные параметры URL, по которому будут отправлены данные формы, необходимо передать анонимный объект, свойства которого будут преобразованы в пары ключ-значение. Для определения метода отправки формы, в качестве параметра нужно передать значение перечислимого FormMethod.

<% using (Html.BeginForm("About", "Home",

new { hello = "world", answer = 42 }, FormMethod.Get )) { %>

<% } %>

Эти параметры будут использованы при генерации тега <form>.

<form action="/Home/About?hello=world&amp;answer=42" method="get">

</form>

Текстовые поля, скрытые поля и кнопки

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

<%= Html.TextArea("myText", "Hello world!") %>

В отличие от метода Html.BeginForm, выводящего строковые значения непосредственно в выходной буфер ответа пользователю, вспомогательные методы элементов управления возвращают строку, поэтому для них нужно использовать синтаксис <%= %>. Тогда в разметку страницы будет выведена соответствующая строка.

<textarea cols="20" id="myText" name="myText" rows="2">

la-la-la-la-la-la-la</textarea>

Для создания дополнительных атрибутов вспомогательным методам необходимо передать анонимный объект.

<%= Html.TextBox("myTextBox", "", new { style="color: yellow;",

@class="helloWorld" })%>

Поскольку в качестве имени свойства анонимного объекта нельзя использовать зарезервированные ключевые слова языка C#, то перед такими именами свойств нужно добавить символ @. В результирующий вывод свойство @class войдет как class, без символа @.

<input class="helloWorld" id="myTextBox"

name="myTextBox" style="color: yellow;" type="text" value="" />

Особым случаем является вспомогательный метод Html.CheckBox, поскольку он создает два HTML-элемента управления. Непосредственно элемент "флажок" и "скрытое поле".

<%= Html.CheckBox("myCheckBox", true) %>

Поскольку в случае если элемент управления не будет отмечен пользователем, то его значение на сервер не передается, поэтому необходимо использование скрытого поля.

<input checked="checked" id="myCheckBox" name="myCheckBox"

type="checkbox" value="true" />

<input name="myCheckBox" type="hidden" value="false" />

Стоит отметить, каким образом присваиваются значения элементам управления. При генерации разметки для элемента управления myTextBox механизм представления сначала проверит наличие значения в коллекции ViewData.ModelState для элемента с именем myTextBox: ViewData.ModelState["myTextBox"].Value.RawValue, затем будет использовано значение, переданное в качестве параметра вспомогательному методу. В случае если вспомогательному методу не было передано параметров, то будет осуществлена попытка найти значение в коллекции ViewData: ViewData.Eval("myTextBox"). Подробнее о коллекции ModelState рассказано в разделе, посвященном проверке значений элементов управления.

Элементы-списки

Для генерации списков используются два метода Html.DropDownList() и Html.ListBox(), генерирующие разметку для элементов: управления "выпадающий список" и "список" соответственно. Оба этих вспомогательных метода принимают в качестве параметра коллекцию SelectList.

<%= Html.DropDownList("lstName",

new SelectList( new[] {"John", "Paul", "George", "Rringo"} )) %>

В результате создается разметка, содержащая теги <option>.

<select id="lstName" name="lstName">

<option>John</option>

<option>Paul</option>

<option>George</option>

<option>Rringo</option>

</select>

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

<%= Html.ListBox("lstName",

new MultiSelectList( new[] {"John", "Paul", "George", "Rringo"} )) %>

Тогда будет определено свойство multiple тега <select>.

<select id="lstName" multiple="multiple" name="lstName">

<option>John</option>

<option>Paul</option>

<option>George</option>

<option>Rringo</option>

</select>

Разумеется, в реальных приложениях не всегда удобно создавать отдельно список для элементов форм и хотелось бы использовать коллекцию бизнесобъектов, применяемых в логике приложения. Для этого может быть использован конструктор коллекции SelectList.

SelectList(коллекция объектов,

название поля объекта,  содержащее значение,

название поля объекта, содержащее текст,

выбранное значение

)

Например, в нашем приложении используются объекты типа Person, определение которых представлено далее.

public class Person {

public int Id { get; set; }

public string Name { get; set; }

}

Тогда в методе контроллера для сохранения в коллекцию ViewData коллекцию элементов списка можно передать, используя конструктор SelectList так, как показано далее.

public ActionResult About()

{

List<Person> lst = new List<Person>

{

new Person { Id = 1, Name = "John"},

new Person { Id = 2, Name = "Paul"},

new Person { Id = 3, Name = "George"},

new Person { Id = 4, Name = "Ringo"}

};

ViewData["lstName"] = new SelectList(lst, "Id", "Name", 2);

return View () ;

}

В результате будет создана HTML-разметка, приведенная далее.

<select id="lstName" multiple="multiple" name="lstName">

<option value="1">John</option>

<option selected="selected" value="2">Paul</option>

<option value="3">George</option>

<option value="4">Ringo</option>

</select>

Таким образом, коллекция бизнес-объектов может быть использована для заполнения списков необходимыми данными.

Индикаторы корректности введенных данных

Пользователям свойственно ошибаться при вводе данных, и приложению необходимо уведомлять пользователя о допущенных ошибках и конкретных полях формы, которые заполнены некорректно. Для этого существуют два вспомогательных метода: Html.validationMessage(), который выводит сообщение, относящееся к определенному полю на форме, и Html.validationSummary (), который выводит общую информацию по ошибкам, допущенным при заполнении формы.

Работа этих вспомогательных методов основана на коллекции ModelState, которая упоминалась ранее. В этой коллекции на этапе проверки корректности данных сохраняется информация об ошибках, связанных с конкретными полями формы. Пример действия контроллера, выполняющего проверку корректности введенных данных (валидацию), приведен в листинге 5.7.

Листинг 5.7. Пример валидации данных

[AcceptVerbs(HttpVerbs.Post)]

public ActionResult Edit(Product obj, int id)

{

if (obj.UnitsOnOrder < 0)

ModelState.AddModelError("UnitsOnOrder",

"Количество заказанных единиц товара не может

быть отрицательным.");

if (obj.UnitsInStock < 0)

ModelState.AddModelError("UnitsInStock",

"Количество единиц товара на складе должно быть не

отрицательным.");

if (obj.UnitPrice <= 0)

ModelState.AddModelError("UnitPrice",

"Цена должна быть больше нуля.");

if (!ModelState.IsValid)

{

// есть ошибки, еще раз

// показать форму редактирования

return View(obj);

}

else

{

// ошибок нет, сохранить

db.SaveProduct(obj);

return RedirectToAction("Index");

}

}

Процесс валидации прост — выполняется проверка условий и в случае наличия ошибок в коллекцию Modelstate добавляется информация в виде пары "идентификатор элемента — описание допущенной ошибки". Если в коллекцию Modelstate добавлена хотя бы одна такая пара, то значение свойства Modelstate.isValid будет установлено в false. В случае если ошибки допущены, то необходимо снова отобразить то же представление, которое использовалось для радактирования данных, и передать ему те данные, которые были введены пользователем на предыдущем шаге. Пример такого представления, работающего с кодом, описанным в листинге 5.7, показан в листинге 5.8, там же приведено строго типизированное представление, в качестве модели использующее класс Product.

Листинг 5.8. Представление Edit.aspx

<%@ Page Title="" Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<MvcViewsDemo.Models.Product>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Edit

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

<h2>

Редактирование сведений о товаре

</h2>

<%= Html.ValidationSummary("npи редактировании сведений

о товаре произошли ошибки.") %>

<% using (Html.BeginForm())

{%>

<fieldset>

<legend>Редактирование сведений о товаре</legend>

<p>

<label for="ProductID">

Код продукта:

</1аЬе1>

<%= Model.ProductID.ToString() %>

<%= Html.Hidden("ProductId", Model.ProductID)%>

</p>

<p>

<label for="ProductName">

Название:

</label>

<%= Html.TextBox("ProductName", Model.ProductName) %>

<%= Html.ValidationMessage("ProductName", "*") %>

</p>

<p>

<label for="UnitPrice">

Цена:

</label>

<%= Html.TextBox("UnitPrice",

String.Format("{0:F}", Model.UnitPrice)) %>

<%= Html.ValidationMessage("UnitPrice", "*") %>

</p>

<p>

<label for="UnitsInStock">

На складе:

</label>

<%= Html.TextBox("UnitsInStock", Model.UnitsInStock) %>

<%= Html.ValidationMessage("UnitsInStock", "*") %>

</p>

<p>

<label for="UnitsOnOrder">

Заказано:

</label>

<%= Html.TextBox("UnitsOnOrder", Model.UnitsOnOrder) %>

<%= Html.ValidationMessage("UnitsOnOrder", "*") %>

</p>

<p>

<input type="submit" value="Save" />

</p>

</fieldset>

<% } %>

<div>

<%=Html.ActionLink("K списку товаров", "Index") %>

</div>

</asp:Content>

В листинге 5.8 методы Html.ValidationMessage() вызываются co вторым строковым параметром, указывающим сообщение, которое должно быть отображено пользователю в случае наличия ошибки в коллекции ModelState. В результате форма, заполненная с ошибками, будет выглядеть так, как показано на рис. 5.2.

Для того чтобы сообщение об ошибке было выведено непосредственно в месте вызова метода Html.ValidationMessage(), метод нужно вызывать без указания второго параметра Html.ValidationMessage("UnitPrice"). Результат приведен на рис. 5.3.

Стоит отметить, что если в коде представления не используется строготипизированная привязка к свойствам модели, то привязка к данным осуществляется автоматически, и в этом случае при возникновении ошибок нет необходимости передавать объект модели представлению через метод View(), как это было сделано в листинге 5.7. То есть фрагмент кода из листинга 5.7 может быть написан так, как указано далее. Листинг 5.9 демонстрирует код представления, не использующего привязку к свойствам объекта модели Model.

if (IModelState.IsValid)

{

// есть ошибки, еще раз

// показать форму редактирования

return View();

}

Листинг 5.9. Представление Edit.aspx без привязки к свойствам объекта Model

<%@ Page Title="" Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<MvcViewsDemo.Models.Product>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">

Edit

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

<h2>

Редактирование сведений о товаре

</h2>

<%= Html.ValidationSummary("при редактировании сведений

о товаре произошли ошибки.") %>

<% using (Html.BeginForm())

{%>

<fieldset>

<legend>Редактирование сведений о товаре</legend>

<p>

<label for="ProductID">

Код продукта:

</label>

<%= ViewData.Eval("ProductID") %>

<%= Html.Hidden("ProductID")%>

</p>

<p>

<label for="ProductName">

Название:

</label>

<%= Html.TextBox("ProductName") %>

<%= Html.ValidationMessage("ProductName") %>

</p>

<p>

<label for="UnitPrice">

Цена:

</label>

<%= Html.TextBox("UnitPrice") %>

<%= Html.ValidationMessage("UnitPrice") %>

</p>

<p>

<label for="UnitsInStock">

На складе:

</label>

<%= Html.TextBox("UnitsInStock") %>

<%= Html.ValidationMessage("UnitsInStock") %>

</p>

<p>

<label for="UnitsOnOrder">

Заказано:

</label>

<%= Html.TextBox("UnitsOnOrder") %>

<%= Html.ValidationMessage("UnitsOnOrder") %>

</p>

<p>

<input type="submit" value="Save" />

</p>

</fieldset>

<% } %>

<div>

<%=Html.ActionLink("K списку товаров", "Index") %>

</div>

</asp:Content>

Примечание

Важно обратить внимание, что при использовании кода, аналогичного приведенному в листинге 5.9, поиск значений элементов формы будет осуществляться через ViewData.Eval(), и значение ViewData["SomeProperty"] имеет больший приоритет, чем ViewData.Model.SomeProperty. Поэтому, во избежание трудноуловимых ошибок, при создании кода контроллера стоит с особенной тщательностью относиться к тому, как передаются данные — через свойства объекта-модели или через коллекцию ViewData.

***************************

Создание собственного вспомогательного метода

Поскольку вспомогательные методы — обычные методы расширения класса HtmlHelper, принимающие произвольный набор параметров и возвращающие строковые значения, то создать свой вспомогательный метод не составляет труда. Например, в листинге 5.10 приведена заготовка вспомогательного метода, отображающего элемент управления для ввода даты.

Листинг 5.10. Вспомогательный метод для отображения элемента для ввода даты

using System.Web.Mvc;

public static class DataPickerHelper {

public static string DatePicker(this HtmlHelper html,

string id, string text)

{

}

}

Такой метод может быть использован в коде представления через синтаксис

<%= Html.DatePicker("id", "name") %>.

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

Конкатенация строк

Самый очевидный способ — сгенерировать разметку конкатенацией строк. Код для этого метода приведен в листинге 5.11.

Листинг 5.11. Реализация метода DatePickerc помощью конкатенации строк

using System.Web.Mvc;

using System.Text;

using System;

using System.Globalization;

public static class DataPickerHelper

{

public static string DatePicker(this HtmlHelper html, string id)

{

return DatePicker(html, id, String.Empty);

}

public static string DatePicker(this HtmlHelper html,

string id, string text)

{

StringBuilder sb = new StringBuilder();

if (!String.IsNullOrEmpty(text))

{

sb.Append("<div id=\"");

sb.Append (id);

sb.Append("\">");

sb.Append(text);

}

/* Day */

sb.Append("<select id=\"day_");

sb.Append(id);

sb.Append("\">");

sb.Append("<option></option>") ;

for (int i = 1; i <= 31; i++)

{

sb.Append("<option>");

sb.Append(i.ToString());

sb.Append("</option>");

sb.Append("</select>");

sb.Append("&nbsp;");

}

/* Month */

sb.Append("<select id=\"month_");

sb.Append(id);

sb.Append("\">");

sb.Append("<option></option>");

for (int i = 0; i <= 11; i++)

{

sb.Append("<option>");

sb.Append(DateTimeFormatInfo.CurrentInfo.MonthNames[i]);

sb.Append("</option>");

}

sb.Append("</select>");

sb.Append("&nbsp;");

/* Year */

sb.Append("<select id=\"year_");

sb.Append(id);

sb.Append("\">");

sb.Append("<option></option>");

for (int i = 1900; i <= DateTime.Now.Year; i++)

{

sb.Append("<option>");

sb.Append(i.ToString());

sb.Append("</option>");

}

sb.Append("</select>");

if (!String.IsNullOrEmpty(text))

{

sb.Append("</div>");

}

return sb.ToString();

}

}

Плюс решения, продемонстрированного в листинге 5.11, — простота реализации "в лоб", копированием кода из макета верстки. Минусы решения очевидны — поддержка такого кода сложна за счет необходимости работы с кодом, перемешанным с большим количеством строковых констант.

Использование ресурсов

Упростить модификацию самой разметки и внесение в нее косметических изменений можно за счет размещения статических строковых констант в файлах ресурсов. Генерацию финальной разметки при этом можно выполнять, используя только методы форматирования строк, как это показано в листинге 5.12.

Листинг 5.12. Реализация метода DatePickerc помощью ресурсов

public static string DatePicker(this HtmlHelper html,

string id, string text)

{

return String.Format(Resources.DatePicker, id, text,

Resources.DaysOptions,

Resources.MonthsOptions, Resources.YearsOptions);

}

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

Использование дополнительных слоев абстракции

Достигнуть большего контроля над логикой и разметкой можно за счет использования дополнительной абстракции над созданием самой разметки, вынесением отдельных методов, генерирующих повторяющие элементы, и созданием тегов с помощью специального класса TagBuilder. В WebForms при создании контролов (Custom Controls) используется похожий подход.

TagBuilder активно применяется в расширениях, входящих в саму сборку System.Web.Mvc, в чем можно убедиться, посмотрев, например, на исходный код System.Web.MVC.SelectExtensions.

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

Листинг 5.13. Реализация метода DatePicker с дополнительными слоями абстракции

public static class DataPickerHelper

{

private static string DAY_PREFIX = "day_";

private static string MONTH_PREFIX = "month_";

private static string YEAR_PREFIX = "year_";

private static string ListItemToOption(SelectListItem item)

{

TagBuilder builder = new TagBuilder("option")

{

InnerHtml = HttpUtility.HtmlEncode(item.Text)

};

if (item.value != null)

builder.Attributes["value"] = item.Value;

if (item.Selected)

builder.Attributes["selected"] = "selected";

return builder.ToString(TagRenderMode.Normal);

}

private static string SelectList(string id,

List<SelectListItem> items)

{

StringBuilder listItemBuilder = new StringBuilder();

foreach (var item in items)

{

listItemBuilder.AppendLine(ListItemToOption(item));

}

TagBuilder tagBuilder = new TagBuilder("select")

{

InnerHtml = listItemBuilder.ToString()

};

tagBuilder.Attributes.Add("id", id);

tagBuilder.Attributes.Add("name", id);

return tagBuilder.ToString(TagRenderMode.Normal);

}

public static string DatePicker(this HtmlHelper html, string id)

{

return DatePicker(html, id, String.Empty);

}

public static string DatePicker(this HtmlHelper html,

string id, string text)

{

// buffer

StringBuilder sb = new StringBuilder();

// generate days

List<SelectListItem> days = new List<SelectListItem>();

string dayValue = GetValue(html, DAY_PREFIX + id);

for (int i = 0; i <= 31; i++)

{

days.Add(new SelectListItem

{

Text = (i == 0) ? String.Empty : i.ToString(),

Value = i.ToString(),

Selected = (dayValue == i.ToString())

});

}

sb.AppendLine(SelectList(DAY_PREFIX + id, days));

// generate months

List<SelectListItem> months = new List<SelectListItem>();

string monthValue = GetValue(html, MONTH_PREFIX + id);

for (int i = 0; i <= 12; i++)

{

months.Add(new SelectListItem

{

Text = (i == 0) ? String.Empty :

DateTimeFormatInfo.CurrentInfo.MonthNames[i — 1],

Value = i.ToString(),

Selected = (monthValue == i.ToString())

});

}

sb.AppendLine(SelectList(MONTH_PREFIX + id, months));

// generate years

List<SelectListItem> years = new List<SelectListItem>();

string yearValue = GetValue(html, YEAR_PREFIX + id);

for (int i = 1900; i <= DateTime.Now.Year; i++)

{

years.Add(new SelectListItem

{

Text = (i == 1900) ? String.Empty : i.ToString(),

Value = i.ToString(),

Selected = (yearValue == i.ToString())

});

}

sb.AppendLine(SelectList(YEAR_PREFIX + id, years));

// parent tag

if (!String.IsNullOrEmpty(text))

{

TagBuilder div = new TagBuilder("div");

div.Attributes.Add("id", id);

div.InnerHtml = text + sb.ToString();

sb = new StringBuilder(

div.ToString(TagRenderMode.Normal));

}

return sb.ToString();

}

private static string GetValue(HtmlHelper html, string id)

{

object o = null;

if (html.ViewData != null)

o = html.ViewData.Eval(id);

if (o == null)

o = html.ViewContext.RequestContext.HttpContext.Request.Params[id];

return (o == null) ? String.Empty : o.ToString();

}

}

Использование серверных элементов управления WebForms

В главе 2, в разд. "Использование элементов управления WebForms в MVC-приложениях” уже была продемонстрирована возможность применения серверных элементов управления в представлениях MVC. Как уже было сказано ранее, использование серверных элементов управления может быть оправдано, если не требуется интерактивное взаимодействие с соответствующим элементом, и он используется только для генерации разметки.

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

Сделать это можно просто, учитывая, что класс Webcontrol, которому наследуют классы конкретных элементов управления, содержит метод Render(), генерирующий разметку. Как раз метод Render() применяет инфраструктура WebForms для всех элементов управления на страницах. Пример использования элемента управления WebForms приведен в листинге 5.14.

Листинг 5.14. Пример использования класса Button во вспомогательном методе

public static class WebFormsHelper {

public static string WebFormsButton(this HtmlHelper html)

{

Button control = new Button { Text = "Web Forms Button" };

StringBuilder sb = new StringBuilder();

HtmlTextWriter htmlWriter = new HtmlTextWriter(

new StringWriter(sb));

control.RenderControl(htmlWriter);

return sb.ToString();

}

}

Листинг 5.14 демонстрирует концепцию использования серверных элементов управления: создать экземпляр класса элемента управления, задать его свойства, вызвать при необходимости методы, а затем сгенерировать разметку, которая будет возвращена вспомогательным методом.

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

Частичные представления

Ранее в этой главе уже говорилось об использовании частичных представлений. Механизм частичных представлений позволяет многократно использовать разметку в разных методах контроллеров, аналогично примеру из листингов 5.1—5.3. Кроме того, частичные представления могут быть использованы для отображения списков элементов. Так, в листинге 5.15 приведено частичное представление, которое используется для отображения строк таблицы товаров в представлении Index.aspx, код которого приведен в листинге 5.16.

Листинг 5.15. Частичное представление ProductListItem.ascx

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<

MvcViewsDemo.Models.Product>" %>

<tr>

<td>

<%= Html.ActionLink("Изменить", "Edit", new { id=Model.ProductID }) %>

</td>

<td>

<%= Html.Encode(Model.ProductID)%>

</td>

<td>

<%= Html.Encode(Model.ProductName)%>

</td>

<td>

<%= Html.Encode(String.Format("{0:F}", Model.UnitPrice))%>

</td>

<td>

<%= Html.Encode(Model.UnitsInStock)%>

</td>

<td>

<%= Html.Encode(Model.UnitsOnOrder)%>

</td>

</tr>

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

<%@ Page Title="" Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<IEnumerable<

MvcViewsDemo.Models. Product»" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Список товаров

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<h2>

Список товаров

</h2>

<table>

<tr>

<th>

</th>

<th>

Код товара </th>

<th>

Название

</th>

<th>

Цена

</th>

<th>

На складе

</th>

<th>

Заказано

</th>

</tr>

<% foreach (var item in Model)

{ %>

<% Html.RenderPartial("ProductListItem", item); %>

<% } %>

</table>

</asp:Content>

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

Создание гаджетов

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

Разумеется, можно реализовать похожую функциональность так, как это показано в листингах 5.1—5.3, разместив частичные представления на мастерской странице. Однако часто оказывается удобным вынести функциональность гаджета в отдельное представление и полностью отделить логику гаджета от основных представлений. В поставку MVC Framewrok функциональность по созданию гаджетов не входит, однако она доступна в проекте MVC Futures. Скачать код и сборку MVC Futures (http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24471) можно на странице проекта MVC Framework на портале CodePlex. После подключения этой сборки к проекту функциональность по созданию гаджетов будет доступна в проекте.

Примечание

В проект MVC Futures входит код, не вошедший по каким-либо причинам в основную поставку MVC Framework. Причины могут быть разными — от недостаточной стабильности кода до желания разработчиков придумать лучшее решение в следующей версии. Однако вас не должна страшить потенциальная возможность того, что поддержка гаджетов никогда не будет включена в том виде, в котором она представлена в MVC Futures, в сам MVC Framework, поскольку вам доступен полный исходный MVC Futures, и вы можете использовать его непосредственно в ваших проектах. Более того, вы можете выделить только ту часть исходного кода, которая используется в ваших проектах, и перенести его из сборки MVC Futures Microsoft.Web.Mvc.dll в сборку вашего проекта.

***************************

Собственно все, что необходимо для создания гаджетов — это вспомогательный метод Html.RenderAction(), который позволяет включить на страницу вывод произвольного действия произвольного контроллера. Например, на некоторых страницах сайта нужно добавить независимый блок, выводящий информацию о текущем курсе доллара. Для этого создается частичное представление, разметка которого приведена в листинге 5.17, и контроллер, код которого приведен в листинге 5.18.

Листинг 5.17. Частичное представление ExchangeRates.ascx

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<table style="border: solid 2px red; margin: 10px;">

<tr>

<td>

1 USD =

</td>

<td>

<%= ViewData["USD"] %> RUB

RUB

</td>

</tr>

</table>

Листинг 5.18. Контроллер GadgetsController

using System.Web.Mvc;

using MvcViewsDemo.Services;

namespace MvcViewsDemo.Controllers

{

public class GadgetsController : Controller

{

public ActionResult ExchangeRates()

{

ViewData["USD"] = ExchangeRatesService.GetRate("USD");

return View();

}

}

}

Использовать гаджет ExchangeRates можно в любом представлении. Например, при использовании в представлении Index, код которого показан в листинге 5.19, получается результат, приведенный на рис. 5.4.

Листинг 5.19. Представление Index.aspx, использующее гаджет ExchangeRates

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<%@ Import Namespace="Microsoft.Web.Mvc" %>

<%@ Import Namespace="MvcViewsDemo.Models" %>

<asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent"

runat="server">

Домашняя страница

</asp:Content>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent"

runat="server">

<h2>

<%= Html.Encode(ViewData["Message"]) %>

</h2>

<table>

<thead>

<tr>

<th>

Название компании

</th>

<th>

Контактное лицо

</th>

</tr>

</thead>

<% foreach (

Customer c in (IEnumerable<Customer>)ViewData["Customers"])

{ %>

<tr>

<td>

<%= c.CompanyName %>

</td>

<td>

<%= c.ContactName %>

</td>

</tr>

<% } %>

</table>

<% Html.RenderAction("ExchangeRates", "Gadgets"); %>

</asp:Content>

В листинге 5.19 отмечено, что для использования метода Html.RenderAction() необходимо подключить пространство имен Microsoft.Web.Mvc. Также из листинга 5.19 видно, что гаджету не передается никаких дополнительных данных, поскольку он полностью независим от страницы, на которой отображается.

Примечание

Для того чтобы не добавлять директиву Import в разметку представления, можно подключить пространство имен Microsoft.Web.Mvc для всех файлов проекта в разделе namespaces файла web.config.

*********************

Удобство использования гаджетов для независимых блоков на страницах в том, что в процессе развития проекта могут меняться контроллеры, действия и представления, используемые веб-приложением, однако код независимых блоков легко может быть перенесен на другие страницы и модифицирован, просто лишь перестановкой вызова Html.RenderAction(). Кроме того, появляется дополнительная степень свободы в модификации самих гаджетов без необходимости затрагивать код основных контроллеров и представлений. Например, код гаджета может быть доработан так, как показано в листингах 5.20, 5.21, чтобы получить результат, представленный на рис. 5.5.

Листинг 5.20. Доработанное частичное представление ExchangeRates

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<table style="border: solid 2px red; margin: 10px;">

<% foreach (var rate in (Dictionary<string, double>)ViewData["rates"])

{ %>

<tr>

<td>

1

<%= rate.Key %>

</td>

<td>

<%= rate.Value %> RUB

</td>

</tr>

<% } %>

</table>

Листинг 5.21. Доработанный контроллер Gadgets

using System.Web.Mvc;

using MvcViewsDemo.Services;

using System. Collections.Generic;

namespace MvcViewsDemo.Controllers

{

public class GadgetsController : Controller

{

public ActionResult ExchangeRates()

{

Dictionary<string, double> rates =

new Dictionary<string, double>();

rates.Add("USD", ExchangeRatesService.GetRate("USD"));

rates.Add("EUR", ExchangeRatesService.GetRate("EUR"));

ViewData["Rates"] = rates;

return View();

}

}

}

В качестве представлений для гаджетов могут использоваться не только частичные представления ASCX, но и полноценные представления ASPX, включая поддержку мастерских страниц. Однако в большинстве случаев гаджеты являются лишь небольшими фрагментами HTML-разметки, и использование частичных представлений выглядит органично.

Заключение

Материала, представленного в главах 1—5, достаточно для того, чтобы начать создавать базовые веб-приложения с использованием MVC Framework. В следующих главах вы познакомитесь ближе с механизмами маршрутизации и разработкой клиентской части веб-приложений и будете готовы к разработке веб-приложений любой сложности.

ГЛАВА 6

Механизмы маршрутизации

Начиная с версии .NET Framework 3.5 SP1, ASP.NET содержит новый механизм маршрутизации пользовательских запросов. Основным предназначением механизма маршрутизации является предоставление возможности осуществлять запросы к веб-приложению не на основании файлов и файловой структуры приложения, а на основании специально определенных шаблонов, которые называются маршрутами.

Механизм маршрутизации не является составной частью MVC Framework. Представленный в .NET Framework 3.5 SP1, этот механизм является составной частью ASP.NET и может быть использован в любом проекте ASP.NET, основанном как на WebForms, так и на MVC Framework.

И хотя маршрутизация — это не часть MVC Framework, тем не менее в проектах на базе MVC Framework она играет одну из ключевых ролей. Маршрутизация помогает перейти от запросов к файлам ASPX, к запросам на основании набора контроллеров и действий. Такой переход позволяет избавиться от зависимости от строки запроса, которая в классическом ASP.NET во многом определяла структуру приложения. Кроме того, с помощью маршрутизации проекты на базе MVC Framework изначально получают возможность формирования удобочитаемых URL, что имеет большое значение в оптимизации приложения для индексации поисковыми системами.

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

Маршрутизация в ASP.NET

Механизм маршрутизации ASP.NET был представлен в .NET Framework 3.5 SP1 и представляет собой набор классов, объединенных в пространстве имен System.Web.Routing. В состав System.Web.Routing входят следующие основные классы и интерфейсы:

□ класс UrlRoutingModule реализует интерфейс iHttpModule для обработки клиентских запросов и последующего сопоставления данных запроса одному из маршрутов, определенных в приложении;

□ RouteTable представляет собой класс, хранящий таблицу маршрутизации, т. е. все маршруты, используемые в приложении;

□ класс RouteCollection предоставляет организацию и доступ к коллекции маршрутов;

□ класс Route предназначен для определения свойств маршрута и предоставления данных о нем;

□ класс RouteData содержит данные о запрошенном через механизмы RouteCollection маршруте;

□ класс RequestContext содержит информацию о контексте пользовательского запроса, его параметрах и данных, а также информацию о выбранном маршруте. Этот класс является значительным для MVC Framework механизмом, который используется на всех этапах обработки и выполнения запроса;

□ интерфейс IRouteHandler определяет обработчик маршрутов;

□ интерфейс IRouteConstraint определяет условия, налагающие ограничения на параметры маршрута.

Кроме этих классов в пространстве имен System.Web.Routing определены еще некоторые классы и перечисления, которые играют вспомогательную или базовую роль для перечисленных классов и интерфейсов.

Рассмотрим применение классов механизма маршрутизации на примере стандартного проекта MVC Framework. В базовом шаблоне проекта MVC Framework в web.config механизмом, обрабатывающим запросы по умолчанию, назначен механизм маршрутизации, представленный классом UrlRoutingModule. Именно этот модуль определен в секциях httpModules и system.webServer как модуль, обрабатывающий HTTP-запросы.

Когда веб-приложение MVC Framework запускается в первый раз, выполняется метод Application_Start, определенный в global.asax. В проекте по умолчанию MVC Framework определяет в Application_Start инициализацию таблицы маршрутизации, представленную классом RouteTable. RouteTable содержит статическое свойство Routes, которое представляет собой экземпляр коллекции RouteCollection. Routes, с помощью вспомогательного метода RegisterRoutes заполняется маршрутами, которые определяет пользователь. Каждый такой маршрут представляет собой объект типа Route. По умолчанию в проекте MVC Framework создается всего один маршрут, рассмотрим его на следующем фрагменте кода из файла global.asax.cs:

public class MvcApplication : System.Web.HttpApplication

{

public static void RegisterRoutes(RouteCollection routes)

{

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

routes.MapRoute(

"Default",

"{controller}/{action}/{id}",

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

);

}

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

}

}

Здесь для таблицы маршрутизации RouteTable.Routes выполняются два действия. Во-первых, вызывается метод IgnoreRoute, который определяет в таблице правило игнорирования маршрута для запросов, содержащих ссылки на AXD-файлы. Определяя правило игнорирования, вы исключаете запрос, который должен быть обработан другим обработчиком, из маршрутизации.

Во-вторых, вызывается метод расширения MapRoute, который регистрирует единственный маршрут в таблице маршрутизации. Для этого в данном конкретном примере он принимает три параметра: наименование маршрута, шаблон маршрута и определение значений параметров шаблона по умолчанию. Наименование маршрута, определенное как Default, может быть использовано в дальнейшем для обращения к маршруту и оперирования с ним. Более подробно разберем шаблон маршрута и параметры по умолчанию.

Шаблон маршрута, представленный строкой {controller}/{action}/{id}, описывает правило, которому будут подчинены клиентские запросы относительно веб-сайта. Правило содержит параметры шаблона: controller, action и id. Первые два из них — это стандартные параметры MVC Framework, которые позволяют задавать в шаблоне определение контроллера и действия соответственно. Параметр id — это пользовательский параметр, который будет передан действию. Например, при обращении к сайту sample.domain по следующему адресу http://sample.domain/home/index/5 механизм маршрутизации сопоставит параметру шаблона controller значение home, параметру action — значение index, параметру id — значение 5. На практике это будет означать следующее: механизм маршрутизации передаст механизму MVC Framework информацию о том, что в ответ на клиентский запрос необходимо вызвать действие Index у контроллера HomeController и передать действию 5 в виде значения параметра id.

Значения параметров шаблона маршрута по умолчанию, которые задаются в MapRoute в виде new { controller = "Home", action = "Index", id = "" }, представляют собой значения для параметров маршрута, которые будут использованы в том в случае, когда клиентский запрос их не содержит. Например, если обратиться к ресурсу со следующим запросом http://sample.domain/About/, в котором определен только первый параметр из шаблона {controller}/{action}/{id} , то механизм маршрутизации автоматически определит оставшиеся два на основании значений по умолчанию. То есть параметр controller получит значение About, а параметры action и id значения Index и пустую строку соответственно. Другими словами, на основании значений параметров по умолчанию запрос http://sample.domain/About/ будет интерпретироваться механизмом маршрутизации как запрос http://sample.domain/About/Index/. Что приведет к вызову действия Index у контроллера AboutController.

Здесь мы поверхностно рассмотрели работу механизма маршрутизации и то, как он участвует в работе с MVC Framework. В следующих разделах данной главы мы рассмотрим маршрутизацию более подробно.

Механизмы маршрутизации

В начале главы мы упомянули об основных классах, которые составляют механизм маршрутизации. В этой части главы мы рассмотрим их более подробно.

Маршрут и класс Route

Маршрут в понятии ASP.NET — это строка, которая представляет собой шаблон URL-строки запроса к веб-приложению. Этот шаблон определяет, какие запросы попадают под понятие данного маршрута, а какие нет. Шаблоны маршрутов содержат параметры, имена которых заключены в фигурные скобки. Обычно параметры разделены обратным слэшем (/) как разделяющие сегменты URL-строки. Например, маршрут, определенный следующим образом admin/{user}/{action}, содержит два параметра: user и action. Такому маршруту могут соответствовать следующие строки URL: http://sample.domain/ admin/foo/add/ или http://sample.domain/admin/bee/edit/. Где foo и bee определяются как значения параметра user, а add и edit — параметра action.

Механизм MVC Framework определяет два базовых параметра маршрутов: controller и action, которые предназначены для определения разработчиком месторасположения наименования контроллера и действия в строке запроса. Остальные параметры являются пользовательскими и определяются разработчиком. Например, следующий маршрут {controller}/{action}/{user}/{page} определяет кроме базовых параметров controller и action еще два пользовательских: user и page. Такому маршруту может соответствовать строка запроса http://sample.domain/User/GetUserMessages/user1/2/. Механизм MVC Framework при сопоставлении данных маршрутов и строки запроса определит, что требуется вызвать действие с именем GetUserMessages в контроллере с именем UserController, которому нужно передать два параметра: user со значением user1 и page со значением 2.

Одним из базовых классов маршрутизации ASP.NET является класс Route, который позволяет разработчику определить свойства маршрута. Рассмотрим основные свойства, которые содержит класс Route:

□ Constraints — свойство типа RouteValueDictionary, которое хранит все ограничения, накладываемые разработчиком на маршрут;

□ DataTokens — свойство типа RouteValueDictionary, которое хранит набор параметров, не участвующих в разборе шаблона, но передающихся обработчику маршрута как дополнительная информация;

□ Defaults — свойство типа RouteValueDictionary, которое хранит значения параметров маршрута по умолчанию. Данные значения используются, когда определенная для маршрута строка URL не содержит необходимого параметра;

□ RouteHandler — свойство, реализующее интерфейс IRouteHandler, является обработчиком маршрута, который определяет, подходит или нет заданный URL запроса к маршруту;

□ Url — строковое свойство, которое содержит определение шаблона маршрута.

Создание экземпляра Route не вызывает трудностей, например, в следующем фрагменте представлено создание маршрута, аналогичного тому, что создается в проекте MVC Framework по умолчанию:

var defaults = new RouteValueDictionary

{

{"controller", "Home"},

{"action", "Index"},

{"id", ""}

};

routes.Add(new Route(

"{controller}/{action}/{id}",

defaults,

null,

null,

new MvcRouteHandler()

));

Класс Route имеет несколько конструкторов, конструктор с самым большим числом параметров определен так:

public Route(string url,

RouteValueDictionary defaults,

RouteValueDictionary constraints,

RouteValueDictionary dataTokens,

IRouteHandler routeHandler

)

Рассмотрим параметры, которые передаются в этот конструктор:

□ url — обязательный параметр, определяет строку шаблона для маршрута;

□ defaults — необязательный параметр, определяет значения по умолчанию для параметров маршрута;

□ constraints — необязательный параметр, определяет ограничения для маршрута;

□ dataTokens — необязательный параметр, определяет дополнительные данные для маршрута;

□ routeHandler — обязательный параметр, определяет обработчик, реализующий интерфейс IRouteHandler для обработки маршрута. В MVC Framework обработчиком по умолчанию является класс MVCRouteHandler.

Коллекция маршрутов и класс RouteCollection

Для того чтобы механизм MVC Framework начал работать с маршрутом, который определяет пользователь, необходимо, чтобы маршрут попал в таблицу маршрутизации. Такая таблица основывается на классе RouteCollection, который представляет собой коллекцию маршрутов.

По существу класс RouteCollection представляет собой класс, наследующий от класса Collection<BaseRoute>. То есть RouteCollection содержит все методы по управлению коллекций элементов, такие как Add, Clear, Remove, SetItem и пр. Кроме того, из определения понятно, что RouteCollection может оперировать только элементами типа BaseRoute и его производными, которым является класс Route.

Кроме базовых методов, унаследованных от Collection, в RouteCollection определены следующие методы и свойства:

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

□ GetReadLock, GetWriteLock — методы, которые позволяют организовать потокобезопасные операции с коллекцией маршрутов;

□ GetRouteData — метод, который возвращает информацию о маршруте в виде экземпляра типа RouteData;

□ GetVirtualPath — метод, который возвращает объект типа VirtualPathData, который позволяет получить URL, соответствующий заданным параметрам маршрута;

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

Работа с коллекцией маршрутов в MVC Framework происходит через таблицу маршрутизации RouteTable и статическое свойство Routes, которое является экземпляром RouteCollection.

Для упрощения работы с коллекцией RouteCollection механизм MVC Framework определяет два метода расширения:

□ MapRoute — позволяет добавлять в коллекцию маршрутов новый маршрут;

□ IgnoreRoute — позволяет добавлять в коллекцию маршрутов новый маршрут, который, однако, добавляется с обработчиком маршрутов StopRoutingHandler, что означает игнорирование механизмом маршрутизации указанного маршрута.

Рассмотрим, как работают эти методы расширения. Метод MapRoute имеет несколько вариантов, далее представлено определение для метода с самым большим числом параметров:

public static Route MapRoute(

this RouteCollection routes,

string name,

string url,

object defaults,

object constraints,

string[] namespaces

)

Все варианты метода расширения MapRoute, определенные в MVC Framework, для добавления маршрута требуют указания наименования маршрута, которое задается через параметр name. Параметр url определяет шаблон маршрута, а параметры defaults и constraints — словари с набором параметров по умолчанию и ограничений. Методы расширения MapRoute не содержат возможности задавать значения для свойства DataTokens, как это делает настоящий конструктор маршрута, и на это есть причина. Поскольку MVC Framework имеет работающий по умолчанию обработчик для маршрутов в виде класса MvcRouteHandler, надобность в пользовательских параметрах, которые передаются для обработчика через DataTokens, отпадает. Однако такие параметры и DataTokens обработчик MvcRouteHandler все же использует. Через параметр namespaces метода расширения MapRoute разработчик может задать массив наименований пространств имен. Этот массив передается в DataTokens и в дальнейшем используется механизмом MVC Framework для поиска классов контроллеров только в тех пространствах имен, которые в нем определены.

Метод IgnoreRoute, в своем самом большом варианте, определен следующим образом:

public static void IgnoreRoute(

this RouteCollection routes,

string url,

object constraints

)

Параметров у метода всего два. Первый — url — определяет маршрут, который подлежит игнорировать. Второй — constraints — содержит словарь ограничений для параметров маршрута, что позволяет более гибко настраивать игнорирование маршрутов. На самом деле IgnoreRoute создает маршрут, но сопоставляет ему не стандартный для MVC Framework обработчик MvcRouteHandler, а обработчик StopRoutingHandler, определенный в механизме маршрутизации ASP.NET, который предназначен для пропуска маршрутов механизмом маршрутизации.

Таблица маршрутизации и класс RouteTable

Как уже сообщалось, одним из основных классов механизма маршрутизации является класс RouteTable. Вместе с этим RouteTable — один из самых простых классов, он содержит только одно свойство Routes. Это статическое свойство, которое содержит коллекцию маршрутов в виде экземпляра класса RouteCollection.

Для работы MVC Framework необходимо, чтобы свойство Routes содержало хотя бы один маршрут. RouteTable можно считать контейнером для маршрутов всего приложения. Так как коллекция маршрутов типа RouteCollection определена в нем в виде статического свойства Routes, доступ ко всем маршрутам будет иметь любая часть приложения.

Ограничения и интерфейс IRouteConstraint

Интерфейс IRouteConstraint предназначен для определения объекта ограничения, который, основываясь на некоторой логике, определяет, подходит или нет значение параметра URL маршруту, которому присваивается это ограничение. Проще говоря, IRouteConstraint позволяет определить объект и сопоставить его имени параметра маршрута. Задачей этого объекта является проверка значений параметра на соответствие неким условиям. MVC Framework при сопоставлении URL запроса маршруту последовательно вызывает все зарегистрированные объекты, реализующие IRouteConstraint, и таким образом проверяет, подходит ли данный набор параметров URL рассматриваемому маршруту.

Интерфейс IRouteConstraint задает всего один метод Match, который имеет следующее определение:

bool Match(

HttpContextBase httpContext,

Route route, string parameterName,

RouteValueDictionary values,

RouteDirection routeDirection

)

Метод Match должен содержать логику проверки параметра строки URL запроса на соответствие некоторым условиям. Match должен вернуть true в случае, когда значение параметра соответствует условиям, и false в обратном случае. При вызове методу Match передаются следующие параметры:

□ httpContext — контекст запроса в виде экземпляра класса HttpContextBase;

□ route — маршрут, к которому применяется данное ограничение;

□ parameterName — имя параметра, значение которого следует проверить на условия ограничения;

□ values — коллекция значений параметров запроса;

□ routeDirection — параметр, определяющий текущее поведение механизма маршрутизации: обработку клиентского запроса или создание строки URL на базе маршрутов.

Основываясь на перечисленных параметрах, метод Match должен определить, подходит ли значение параметра из строки URL для параметра маршрута.

Рассмотрим работу интерфейса на примере:

public class SampleConstraint : IRouteConstraint

{

public bool Match(HttpContextBase httpContext,

Route route,

string parameterName,

RouteValueDictionary values,

RouteDirection routeDirection)

{

bool result = false;

if (parameterName == "user")

{

if (values["user"].ToString().Length >= 4) result = true;

}

return result;

}

}

Данный класс SampleConstraint реализует интерфейс IRouteConstraint и определяет метод Match. В этом методе происходит проверка значения параметра под именем user. Если длина значения параметра менее 4 символов, то возвращается false, который указывает, что параметр не прошел проверку, в ином случае возвращается true, что говорит о прохождении параметров проверки на условия. Образно говоря, этот класс проверяет длину строки имени пользователя, которая была передана в строке URL запроса.

Для того чтобы использовать этот класс ограничения, необходимо сопоставить его маршруту следующим образом:

routes.MapRoute("Default",

"{controller}/{action}/{user}",

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

new {user = new SampleConstraint() }

);

По этому определению маршрута будет следовать, что запрос со строкой URL http://sample.domain/Home/Index/user1 обработается, а запрос http://sample.domain/Home/Index/foo будет отклонен на этапе работы ограничения SampleConstraint, т. к. значение foo, определяющее параметр маршрута user, содержит менее 4 символов.

Обработчик маршрутов и интерфейс IRouteHandler

Интерфейс IRouteHandler предназначен для определения обработчика маршрута. Такой обработчик нужен для того, чтобы обработать запрос после определения маршрута. Иными словами, после клиентского запроса и определения подходящего для него маршрута механизм маршрутизации создает сопоставленный найденному маршруту обработчик и вызывает его. Обработчик должен содержать некую логику, которая исполняется в ответ на клиентский запрос. Для MVC Framework такая логика реализуется с помощью двух классов: MvcRouteHandler и MvcHandler.

Задача класса, реализующего iRouteHandler, состоит в том, чтобы вернуть подходящий экземпляр класса HTTP-обработчика, реализующего iHttpHandler. Для этого интерфейс IRouteHandler определяет всего один метод GetHttpHandler:

IHttpHandler GetHttpHandler(RequestContext requestContext)

Любой класс, реализующий IRouteHandler, должен реализовать метод GetHttpHandler, который должен возвращать инстанцированный объект HTTP-обработчика. В механизме MVC Framework за это отвечает класс MvcRouteHandler, который через GetHttpHandler возвращает экземпляр другого класса MvcHandler. Класс MvcRouteHandler сопоставляется через метод расширения MapRoute всем маршрутам по умолчанию, поэтому разработчику нет нужды напрямую его использовать.

Таким образом, механизм MVC Framework уже содержит предопределенные элементы в виде реализации интерфейса IRouteHandler и HTTP-обработчика, и в общем случае разработчик использует их. Но вы можете определить свой вариант IRouteHandler, который будет возвращать ваш собственный HTTP-обработчик, отличающийся от MvcHandler. Так вы сможете переопределить поведение механизма MVC Framework на этапе связывания маршрута и объектов модели MVC-приложения.

Создание маршрутов

В предыдущей части этой главы мы уже рассмотрели простой пример создания маршрута и класс Route, который используется для этих целей. При создании маршрута с помощью класса Route важную роль играют параметры имени маршрута, Url и три словаря параметров, определенные свойствами Defaults, Constraints и DataTokens. Рассмотрим их назначение и применение более подробно.

Наименование маршрута

В MVC Framework добавление маршрута реализуется путем вызова одного из вариантов MapRoute, методов расширения RouteCollection. Одним из отличиев MapRoute является требование к обязательному указанию имени маршрута, тогда как стандартные средства RouteCollection позволяют добавить маршрут без указания имени.

Примечание

Следует учесть, что имена для маршрутов должны быть уникальными. При попытке добавить в таблицу маршрутизации маршрут с именем, которое уже существует в таблице, будет вызвано исключение.

********************************

Имя маршрута — это достаточно важная часть маршрутизации в MVC Framework. Есть несколько полезных вариантов использования имени маршрута, рассмотрим их по порядку.

RedirectToRoute

Имя маршрута используется для возврата результата действия в виде RedirectToRouteResult с помощью стандартного метода контроллера RedirectToRoute. Назначение RedirectToRoute — это перенаправление выполнения запроса с одного маршрута на другой. На самом деле, для переадресации на другой маршрут MVC Framework на основании переданного имени маршрута генерирует строку URL, которая соответствует новому маршруту и производит возврат клиенту ответа в виде требования на переадресацию на новый URL (redirect).

К примеру, допустим определен маршрут с именем AccountLogOn так, как показано далее:

routes.MapRoute(

"AccountLogOn",

"Account/LogOn",

new { controller = "Account", action = "LogOn" }

);

В этом случае вызов RedirectToRoute, который переадресует пользователя на новый маршрут, будет выглядeть так:

public ActionResult SomeAction()

{

return RedirectToRoute("AccountLogOn");

}

После выполнения действия SomeAction пользователь будет перенаправлен на URL Account/LogOn, согласно определению маршрута AccountLogOn.

AjaxHelper

В методах расширения класса AjaxHelper, таких как BeginRouteForm и RouteLink, имя маршрута используется для генерации строки запроса.

BeginRouteForm — это метод расширения, который позволяет упростить создание формы для отправки результатов через Ajax.BeginRouteForm в данном смысле является аналогом BeginForm другого метода расширения класса AjaxHelper, который строит форму на основании определенных значений контроллера и действия. В случае, когда вызывается BeginRouteForm, механизм класса AjaxHelper формирует на базе имени маршрута строку URL и подставляет ее атрибуту action при рендеринге формы в представлении.

RouteLink — это метод расширения, позволяющий упростить создание ссылки в представлении, которая осуществляла бы Ajax-запросы. Роль имени маршрута при работе RouteLink точно такая же, как и в BeginRouteForm — по имени маршрута строится URL-строка, которая рендерится в представлении в виде атрибута href.

UrlHelper

В методе расширения RouteUrl класса UrlHelper имя маршрута используется для создания строки URL, соответствующей маршруту.

Шаблон маршрута и свойство Url

При создании маршрута строковый параметр Url определяет шаблон маршрута, который, как правило, задает некоторую группу возможных клиентских запросов. Следует учитывать, что при наличии нескольких маршрутов механизм маршрутизации ASP.NET всегда выбирает самый первый из них — тот, что был добавлен в таблицу маршрутизации первым.

Как мы уже говорили, по умолчанию MVC Framework создает один-единственный маршрут с именем Default и шаблоном {controller}/{action}/{id}. Этот маршрут хорош тем, что он один позволяет обрабатывать большую часть возможных пользовательских запросов. По сути такой шаблон говорит о том, что данный маршрут определяет все запросы с вложениями до третьего уровня, т. е. этот маршрут обработает и http://sample.domain/level1/ и http://sample.domain/level1/level2/, и http://sample.domain/level1/level2/level3/, где level1, level2 и level3 могут принимать любые значения. На самом деле это очень большое количество возможных запросов и на практике один маршрут Default покрывает все требования разработчиков к маршрутизации.

Однако разработчик может добавить гибкости своему проекту и улучшить представления строк URL, если определит свои маршруты. Далее представлено два подобных маршрута:

routes.MapRoute(

"AccountLogOn",

"LogOn",

new { controller = "Account", action = "LogOn" }

);

routes.MapRoute(

"Home",

"{action}",

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

);

Первый вызов MapRoute создает маршрут под наименованием AccountLogOn, шаблон которого четко соответствует только одному возможному клиентскому запросу http://sample.domain/Logon. Второй вызов создает маршрут Home более широкого определения. Под этот маршрут попадают все клиентские запросы вида http://sample.domain/Home/{action}.

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

public ActionResult SomeAction()

{

return RedirectToRoute("AccountLogOn");

}

Другим видимым преимуществом этого маршрута является то, что согласно ему клиентский запрос не обязательно должен содержать в себе наименование контроллера. Таким образом, путь http://some.domain/Account/LogOn уменьшается до http://some.domain/LogOn, что придает ссылкам вебприложения более компактный вид. Компактность строк запросов может играть свою роль в случае, когда в большом веб-приложении используются десятки контроллеров с массой действий и параметров.

Значения параметров маршрута по умолчанию и свойство Defaults

Свойство Defaults определяет набор параметров, сопоставляемых параметрам маршрута по умолчанию, в случае, когда URL строки запроса их не содержит. Рассмотрим для примера маршрут {controller}/{action}/{id}, создаваемый в проектах MVC Framework по умолчанию. При его создании свойство Defaults было инициализировано с помощью метода расширения MapRoute следующим значением:

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

На практике это будет означать, что механизм MVC Framework одинаково обработает запросы http://sample.domain/Home/Index/, http://sample.domain/Home/ и http://sample.domain/. Все эти запросы приведут к вызову действия Index в контроллере HomeController. Это стало возможным, поскольку были определены значения по умолчанию для параметров маршрута controller и action. В связи с этим URL http://sample.domain/ при сопоставлении маршруту дополучит часть параметров из словаря Defaults, став, таким образом, равнозначным запросу http://sample.domain/Home/Index/.

Ограничения параметров маршрута и свойство Constraints

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

Чтобы решить задачу с ограничением на длину имени логина в запросе, нужно определить следующее ограничение в свойстве Constraints при создании маршрута:

var constraint = new RouteValueDictionary {

{"user", "\\w{4,}"}

};

routes.Add(new Route(

"{controller}/{action}/{user}/",

defaults,

constraint,

null,

new MvcRouteHandler()

));

Ограничение определяется как элемент словаря RouteValueDictionary, где ключом является имя параметра, а значением регулярное выражение, описывающее правило для параметра. В данном случае регулярное выражение \w{4,} предполагает, что строка должна содержать буквы и цифры в размере от 4 элементов.

После такого определения маршрута, если вы попытаетесь обратиться по следующему адресу http://sample.domain/Home/Index/foo, вы получите стандартное сообщение браузера о возвращенной сервером ошибке с кодом 404 "Страница не найдена".

Ранее в этой главе мы рассмотрели ограничения параметров как коллекцию регулярных выражений в свойстве Constraints класса Route. Однако существует еще один, альтернативный, способ создания маршрута на базе интерфейса iRouteConstraint. Он также описан в этой главе. Вместо того чтобы добавлять в коллекцию Constraints строки с регулярными выражениями, можно воспользоваться интерфейсом IRouteConstraint и реализовать класс, который будет выполнять проверку параметров на соответствие условиям. Добавляется такой класс похожим на обычный способом:

routes.MapRoute("Default",

"{controller}/{action}/{user}",

new {controller = "Home",

action = "Index",

id = ""},

new {user = new SampleConstraint()}

);

Здесь SampleConstraint — это класс, который реализует интерфейс IRouteConstraint.

Параметры маршрута и свойство DataTokens

В механизме маршрутизации ASP.NET при создании маршрута можно указать набор параметров DataTokens. Используя DataTokens, разработчик может передать в маршрут набор данных, которые позднее будут использованы пользовательским вариантом обработчика маршрута при сопоставлении клиентского запроса маршруту. Иными словами, DataTokens помогает определить больше данных для маршрутов в случае, когда пользователь сам определяет обработчик маршрута. В MVC Framework каждому маршруту сопоставляется уже готовый обработчик MvcHandler. Поэтому надобность в пользовательских параметрах, передаваемых через DataTokens, отпадает, очевидно, что эти данные MvcHandler использовать не сможет. В связи с тем, что данные DataTokens в проектах MVC Framework по умолчанию не нужны, в методе расширения MapRoute создание такого набора вовсе отсутствует.

Однако есть исключение, делающее свойство DataTokens экземпляра маршрута полезным даже для проектов MVC Framework. Дело в том, что фабрика контроллеров по умолчанию проверяет DataTokens на наличие параметра Namespaces, от которого в дальнейшем зависит, какие контроллеры могут быть выбраны для инстанцирования.

Параметр Namespaces может содержать строки в виде перечисления типа iEnumerable<string>. Когда фабрика контроллеров находит такой параметр в свойстве DataTokens, она предполагает, что в нем перечислены наименования пространств имен, в которых можно искать контроллеры для инстанцирования в ответ на клиентский запрос.

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

Для того чтобы указать определенный набор пространств имен при создании маршрута, необходимо проделать примерно такие действия:

var route = routes.MapRoute(

"AccountLogOn",

"LogOn",

new { controller = "Account", action = "LogOn" }

);

route.DataTokens = new RouteValueDictionary();

List<string> nsList = new List<string>();

nsList.Add("SomeNamespace");

nsList.Add("SomeNamespace2");

route.DataTokens.Add("Namespaces", nsList);

Здесь после создания собственно маршрута, у него инициализируется свойство DataTokens и заполняется ключом Namespaces со значением списка из двух строк с именами пространств имен SomeNamespace и SomeNamespace2. Такие действия с маршрутом подразумевают, что контроллер для него будет искаться в пространствах имен SomeNamespace и SomeNamespace2.

Еще одна возможность ограничить список пространств имен, в которых фабрика контроллеров ищет контроллеры для инстанцирования, — это свойство DefaultNamespaces класса ControllerBuilder. В каждом приложении MVC Framework существует экземпляр ControllerBuilder в виде статического свойства Current класса ControllerBuilder. Используя свойство DefaultNamespaces, вы можете определить пространства имен по умолчанию, в которых фабрика контроллеров будет искать контроллеры.

ControllerBuilder.Current.DefaultNamespaces.Add("SomeNamespaces3");

DataTokens и DefaultNamespaces можно использовать вместе. В целом очередность работы механизмов DataTokens и DefaultNamespaces в процессе поиска контроллера следующая:

1. Фабрика контроллеров пытается найти контроллер в пространствах имен, определенных в DataTokens маршрута, поиск прекращается, если такой контроллер найден.

2. Фабрика контроллеров пытается найти контроллер в пространствах имен, определенных через DefaultNamespaces, поиск прекращается, если контроллер найден.

3. В конце концов, фабрика контроллеров просматривает все пространства имен в поиске необходимого контроллера.

Здесь следует обратить внимание на то, что определение неверных пространств имен в DataTokens и DefaultNamespaces может привести к тому, что поиск вместо ускорения замедлится, поскольку будет проходить трижды, согласно информации каждого механизма.

Игнорирование маршрутов

Игнорирование маршрутов — это необходимый инструмент, позволяющий указать маршрут, т. е. группу клиентских запросов, которые не будут обрабатываться MVC Framework. Есть множество случаев, когда запрос не должен обрабатываться как запрос к MVC Framework. Например, запросы к изображениям, находящимся на сервере, или к любым другим статическим ресурсам, таким как файлы скриптов или стилей. Нет совершенно никакой необходимости в том, чтобы такие запросы проходили через многоступенчатую обработку MVC Framework. Вместо этого файлы изображений или стилей должны отдаваться клиентам напрямую.

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

Чтобы создать правило игнорирования маршрута, MVC Framework содержит IgnoreRoute — метод расширения класса RouteCollection. Этот метод имеет следующие входные параметры:

□ url — указывает шаблон маршрута, все запросы, которые подпадают под этот маршрут, будут игнорироваться MVC Framework;

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

Когда создается проект MVC Framework через шаблон в Visual Studio, то в файле global.asax автоматически будет сгенерировано определение одного маршрута игнорирования:

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

Это определение маршрута игнорирования достаточно просто демонстрирует, зачем вообще нужно игнорировать маршруты. Определение этого правила необходимо потому, что AXD-файлов на самом деле не существует, и запросы вида some.domain/resource.axd обрабатываются отдельным обработчиком. А так как механизмом MVC Framework игнорируются запросы только к существующим файлам, то определяется, что все запросы к AXD-ресурсам должны обрабатываться не механизмом MVC Framework, но другим обработчиком, который в данном случае определен в web.config как System.Web.Handlers.ScriptResourceHandler.

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

Когда вы не определяете такие иконки на своем сайте либо определяете их через разметку страницы, тогда запрос к отсутствующему файлу приведет к тому, что будет вызван механизм MVC Framework. Для того чтобы такие запросы клиентских браузеров не вызывали работу механизма MVC Framework, нам следует добавить следующее правило игнорирования маршрута:

routes.IgnoreRoute("favicon.ico");

Этим определением мы указываем, что запрос вида http://some.domain/favicon.ico должен игнорироваться. Для более сложного варианта определим игнорирование маршрута к файлу favicon.ico для всех папок нашего сайта, а не только к корневой папке:

routes.IgnoreRoute("{*param}",

new { param = @"(.*/)?favicon.ico(/.*)?" });

Здесь мы уже используем два параметра, первый со значением {*param} определяет шаблон маршрута, в данном случае его можно описать как все пути, которые завершаются со значением параметра шаблона param. Второй параметр new{param=@" (.*/) ?favicon.ico (/.*)?"} задает определение параметра шаблона param в виде регулярного выражения, т. е. определяет, на что должна заканчиваться строка URL в клиентском запросе для того, чтобы маршрут игнорирования сработал.

Рассмотренные примеры работали в режиме, когда MVC Framework и механизм маршрутизации ASP.NET игнорируют запросы к существующим файлам. Однако имеет смысл перестать игнорировать такие запросы и самому обрабатывать запросы к группе определенных файлов, разрешая к ним доступ или запрещая его. Для того чтобы регулировать поведение маршрутизации ASP.NET в плане игнорирования запросов к существующим файлам, у класса RouteCollection, определяющего коллекцию маршрутов, есть булево свойство RouteExistingFiles. По умолчанию значение RouteExistingFiles установлено в false. Установив его в значение true, вы заставите механизм маршрутизации ASP.NET обрабатывать все запросы, в том числе и те, которые ведут на существующие файлы.

routes.RouteExistingFiles = true;

После этого любой запрос на локальный файл приведет к возникновению исключения и возврату клиенту информации об ошибке 404 "Страница не найдена". Теперь вы можете быть уверены в том, что пользователь не получит доступа ни к одному отдельному файлу на вашем сайте. Зато, определив правила игнорирования, для групп таких файлов вы сможете открыть доступ.

Рассмотрим пример использования игнорирования маршрутов для открытия доступа. Предположим, что в вашем проекте все стили, используемые на веб-страницах, расположены в папке some.domain/styles, а скрипты в some.domain/scripts. Теперь, чтобы открыть к ним доступ при включенном механизме маршуртизации для имеющихся файлов, достаточно определить следующие маршруты игнорирования:

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

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

И в заключение рассмотрим последний простой пример, который часто используется на практике. Зачастую структура вашего проекта может содержать файлы с самыми разнообразными расширениями, которые вы отдаете пользователю по его запросу. Скажем, это может быть статический файл помощи с HTML-разметкой или текстовый файл с расширением txt, который может содержать информацию о лицензии. Механизм игнорирования маршрутов позволяет легко предоставить доступ к таким файлам даже при включенном механизме маршрутизации для имеющихся файлов. Например, следующий фрагмент кода разрешает загружать HTML- и TXT-файлы из корня сайта:

routes.IgnoreRoute("{file}.txt");

routes.IgnoreRoute("{file}.htm");

routes.IgnoreRoute("{file}.html");

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

Советы по использованию маршрутов

В этой главе мы рассмотрели механизм маршрутизации ASP.NET, используемые в нем классы, интерфейсы, свойства и коллекции. Мы показали, зачем нужен тот или иной параметр и для чего нужны коллекции параметров типа DataTokens или Constraints. В заключение главы мы расскажем о некоторых полезных советах по использованию механизма маршрутизации на практике.

Маршруты и валидация запросов

Как уже говорилось в этой главе, маршрутизация ASP.NET содержит механизм ограничений, который позволяет более гибко управлять обработкой маршрутов. Но кроме собственно поиска правильного маршрута, этот механизм позволяет также производить валидацию запросов еще на этапе поиска и обработки маршрута.

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

Листинг 6.1. Класс, реализующий IRouteConstraint

public class YearConstraint : IRouteConstraint {

public bool Match(HttpContextBase httpContext,

Route route,

string parameterName,

RouteValueDictionary values,

RouteDirection routeDirection)

{

if (parameterName == "year")

{

try

{

object yearValue = values["year"];

int year = Convert.ToInt32(yearValue);

if (year >= 1900 && year <= 2100) return true;

}

catch

{

return false;

}

}

return false;

}

}

Для того чтобы использовать данный класс, необходимо определить маршрут с параметрами ограничения примерно так, как показано во фрагменте:

var constraints = new RouteValueDictionary

{

{"year", new YearConstraint()}

};

routes.MapRoute("YearData",

"{controller}/{action}/{year}",

new { controller = "Data", action = "Index" },

new { year = new YearConstraint() }

);

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

Хранение маршрутов в базе данных

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

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

Для начала определим две таблицы, Routeitem и Param, для хранения данных о маршрутах так, как продемонстрировано на рис. 6.1 и 6.2.

Таблица Routeitem будет содержать информацию о маршрутах, а Param — соответственно, о параметрах для каждого маршрута.

Чтобы добавить в проект поддержку этих таблиц, создадим с помощью мастера Linq To Sql классы для работы. Получившийся DBML-файл будет представлять схему, показанную на рис. 6.3.

После создания классов Linq To Sql настало время создать логику по регистрации маршрутов в механизме маршрутизации. Для этого создадим класс DatabaseRoutes, представленный в листинге 6.2.

Листинг 6.2. Класс DatabaseRoutes

using System.Linq;

using System.Web.Mvc;

using System.Web.Routing;

namespace Routing {

public class DatabaseRoutes

{

readonly RouteDbDataContext db = new RouteDbDataContext();

private readonly RouteCollection Routes;

public DatabaseRoutes(RouteCollection routes)

{

Routes = routes;

}

public void Register()

{

var routes = db.RouteItems.Where(x => x.State).OrderBy(x => x.LoadOrder);

foreach (var route in routes)

{

RouteValueDictionary defaults = new RouteValueDictionary();

foreach (var param in route.Params)

defaults.Add(param.ParamKey, param.ParamValue);

Routes.Add(route.Name, new Route(

route.Template,

defaults,

new MvcRouteHandler()

));

}

}

}

}

Обратите внимание, конструктор-класс DatabaseRoute принимает параметр типа RouteColection, для того чтобы произвести регистрацию маршрутов. Единственный метод класса Register предназначен для выборки данных из базы данных и инициализации механизма маршрутизации в виде полученного экземпляра RouteColection.

Для того чтобы использовать наш класс, необходимо заполнить таблицы значениями. Сделаем это для определения стандартного маршрута Default так, как представлено на рис. 6.4 и 6.5.

После того как данные внесены в базу данных, можно интегрировать механизм в проект. Для этого следует в global.asax удалить старое определение маршрута Default и добавить инициализацию класса DatabaseRotes так, как показано в следующем фрагменте кода:

public static void RegisterRoutes(RouteCollection routes)

{

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

DatabaseRoutes dbRoutes = new DatabaseRoutes(routes);

dbRoutes.Register();

}

Если вы сделали все правильно, то результатом будет работа вашего проекта на основе маршрута, полученного из базы данных. Теперь, реализовав каким-либо образом доступ к базе данных маршрутов, вы получите возможность предоставить функции редактирования маршрутов администратору без модификации исходных кодов в виде global.asax.

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

Маршрутизация и тестирование

Когда дело касается модульного тестирования механизмов маршрутизации, то определение области тестирования не выглядит очевидным. Что необходимо тестировать? В простейшем случае, когда ваш проект на MVC Framework содержит всего один маршрут Default, определенный по умолчанию, модульное тестирование теряет большую часть смысла. Но в случаях, когда маршрутов в проекте много, повсеместно используется ограничение и игнорирование маршрутов, модульное тестирование обретает широкую область для применения.

Здесь мы на нескольких примерах рассмотрим, как включить в свой проект тесты маршрутов, ограничений и маршрутов игнорирования.

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

Для тестирования маршрутов воспользуемся тремя популярными средствами:

□ NUnit (http://www.nunit.org/index.php) — альтернативное средство тестирования;

□ RhinoMocks (http://ayende.com/projects/rhino-mocks.aspx) — позволяет создавать фальшивые, так называемые, "мок-объекты";

□ MvcContrib (http://www.codeplex.com/MVCContrib) — содержит функционал, расширяющий возможности MVC Framework, в том числе и в сфере модульного тестирования.

Подготовка инструментов

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

MvcContrib.TestHelper.nunit.framework и Rhino.Mocks так, как показано на рис. 6.6.

После этих двух шагов вы готовы для создания модульных тестов механизма маршрутизации. Для тестирования в MvcContrib существует набор специальных методов расширения, которые позволяют значительно упростить создание тестов. Это метод ShouldMapTo<T>, который позволяет протестировать строку определения маршрута, и метод ShouldBeIgnored, который позволяет протестировать правило игнорирования маршрута.

Создание тестов

Для демонстрации создания модульных тестов первым делом определим набор маршрутов, которые будут подвергнуты тестам. Далее представлен фрагмент кода с определением ряда маршрутов:

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

routes.MapRoute(

"Product",

"Product/{id}",

new { controller = "Product", action = "GetById" }

);

routes.MapRoute("ProductList",

"ProductList/{year}",

new { controller = "Product", action = "List" },

new { year = new YearConstraint() }

);

routes.MapRoute(

"Default",

"{controller}/{action}/{id}",

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

);

Как вы можете видеть, в коде определяется три маршрута: Product, ProductList и маршрут по умолчанию Default. Кроме того, определено стандартное правило игнорирования маршрута для игнорирования запросов к

AXD-ресурсам. Обратите внимание, что маршрут с названием ProductList содержит ограничение для параметра year (ранее в этой главе мы рассматривали это ограничение).

Для определения тестов необходимо создать простой класс, например, представленный во фрагменте:

namespace Routing {

using System.Web.Routing;

using MvcContrib.TestHelper;

using NUnit.Framework;

using Routing.Controllers;

[TestFixture]

public class TestRoutes

{

}

}

Обратите внимание на использование атрибута TestFixture. Это атрибут инструмента NUnit, который позволяет определить класс с набором тестов. Добавим в класс простой тест:

[Test]

public void TestSimpleRoute()

{

"~/".Route().ShouldMapTo<HomeController>(x => x.Index());

}

Этот тест направлен на проверку определения маршрута при доступе к сайту по URL без каких-либо параметров или относительных путей. Здесь ожидается, что по умолчанию должен сработать маршрут Default и выполниться действие Index контроллера HomeController.

Для того чтобы запустить наш тест, необходимо скомпилировать проект с тестом и запустить среду NUnit, главное окно которой представлено на рис. 6.7.

C помощью пункта меню File | Open Project добавим в среду сборку нашего проекта тестирования. В моем случае это сборка Routing.dll. После того как сборка загрузится, нажмите кнопку Run для запуска тестов. Как можно убедиться, наш тест не пройден (рис. 6.8).

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

маршрутизации и создает маршруты, необходимые для последующего тестирования:

[TestFixtureSetUp]

public void SetUp()

{

MvcApplication.RegisterRoutes(RouteTable.Routes);

}

[TestFixtureTearDown]

public void TearDown()

{

RouteTable.Routes.Clear();

}

Обратите внимание на атрибуты TestFixtureSetUp и TestFixtureTearDown. Эти атрибуты необходимы для определения кода, который будет вызван перед тестом и сразу после него. В нашем случае перед тестами создаются маршруты, а после теста — разрушаются.

Скомпилируем проект и запустим тест еще раз. На этот раз тест пройден (рис. 6.9).

Для интереса вы можете теперь попробовать модифицировать маршрут Default так, чтобы наш тест перестал работать, например, можно переименовать название действия по умолчанию с Index на Index2. После этого тест будет провален.

Добавим тест для проверки маршрута под названием Product, в нем маршрут определяется простым шаблоном без участия имени действия:

[Test]

public void TestProduct()

{

"~/Product/750".Route()

.ShouldMapTo<ProductController>(x => x.GetById(750));

}

Добавим еще один тест, на этот раз для проверки игнорирования маршрута для AXD-запросов:

[Test]

public void TestIgnoreAxd()

{

"~/someroutetoigonre.axd".ShouldBeIgnored();

}

Запустите тесты и убедитесь, что они пройдены. Обратите внимание на используемый метод расширения ShouldBeIgnored, который предназначен как раз для тестирования игнорирования маршрутов.

Последний наш тест будет направлен на проверку ограничений маршрута. Для тестирования маршрута ProductList определим два следующих теста:

[Test]

public void TestProductListValidYear()

{

"~/ProductList/2009".Route()

.ShouldMapTo<ProductController>(x => x.List(2009));

}

[Test]

public void TestProductListInvalidYear()

{

Assert.AreNotEqual("~/ProductList/1800".Route().Values["controller"],

"Product");

}

Первый тест TestProductListValidYear производит знакомые нам действия, при правильном значении параметра year, ограничение не должно действовать и маршрут должен быть сопоставлен контроллеру Product и действию List. Второй тест TestProductListInvalidYear, наоборот, проверяет поведение маршрута при неверном с точки зрения ограничения параметре year (он должен быть более или равен 1900). Для того чтобы протестировать этот момент, сравниваются имя сопоставленного контроллера и имя контроллера Product. Для успешного прохождения теста они не должны быть равны. Теперь, если убрать ограничение из маршрута, тест будет провален.

После написания всех тестов и запуска NUnit мы должны получить следующую картину успешного прохождения всех тестов (рис. 6.10).

В листинге 6.3 приведен код перечисленных ранее тестов для тех, кто использует тестирование на базе встроенного в Visual Studio инструмента MSTest. Различий минимум и все они касаются именования атрибутов, которое в NUnit отличается от MSTest.

Листинг 6.3. Тестирование с помощью MSTest

namespace Routing

{

using System.Web.Routing;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using MvcContrib.TestHelper; using Routing.Controllers;

[TestClass]

public class TestRoutesMSTest

{

[TestMethod]

public void TestSimpleRoute()

{

"~/".Route().ShouldMapTo<HomeController>(x => x.Index());

}

[TestInitialize]

public void SetUp()

{

MvcApplication.RegisterRoutes(RouteTable.Routes);

}

[TestCleanup]

public void TearDown()

{

RouteTable.Routes.Clear();

}

[TestMethod]

public void TestProduct()

{

"~/Product/750".Route()

.ShouldMapTo<ProductController>(x => x.GetById(750));

}

[TestMethod]

public void TestIgnoreAxd()

{

"~/someroutetoigonre.axd".ShouldBeIgnored();

}

[TestMethod]

public void TestProductListValidYear()

{

"~/ProductList/2009".Route()

.ShouldMapTo<ProductController>(x => x.List(2009));

[TestMethod]

public void TestProductListInvalidYear()

{

Assert.AreNotEqual("~/ProductList/1800".Route()

.Values["controller"], "Product");

}

}

}

Утилита ASP.NET Routing Debugger

Для тестирования и проверки правильности создания маршрутов в вашем приложении может пригодиться небольшой инструмент от разработчиков MVC Framework. Данный инструмент позволяет в режиме отладки проверить все зарегистрированные маршруты на работоспособность. Кроме того, этот инструмент поможет посмотреть на то, как и в каком порядке реагируют ваши маршруты на запросы с различными адресами URL.

Примечание

Инструмент ASP.NET Routing Debugger доступен для скачивания по адресу http://haacked.eom/archive/2008/03/13/u rl-routing-debugger.aspx.

*****************************

Для работы с Routing Debugger необходимо добавить в проект ссылку на сборку RouteDebug.dll и в файле Global.asax добавить одну строку кода в методе Application_Start так, как показано в следующем фрагменте:

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);

}

После этого, запущенный проект вместо ожидаемой страницы выведет специальную страницу с отчетом о зарегистрированных в проекте маршрутах и их параметрах (рис. 6.11).

ASP.NET Routing Debugger может быть полезен, когда ваш проект содержит массу определенных маршрутов. В таком случае вы получаете наглядный инструмент, который покажет вам порядок и параметры маршрутов, и их реакцию на любой запрос. Используя Routing Debugger, вам не придется долго ломать голову над вопросом: "Почему на этот запрос вызывается этот маршрут?"

Заключение

Маршрутизация — это значительный элемент ASP.NET и базовый механизм для работы MVC Framework. Маршрутизация позволяет организовать обработку пользовательских запросов в виде, удобном для построения приложения, согласно паттерну MVC. С использованием маршрутизации в MVC Framework можно отойти от привязки запроса к конкретной странице ASPX и использовать строку запроса как описатель необходимого для вызова действия и контроллера.

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

В этой главе мы рассмотрели механизм маршрутизации ASP.NET, его значение и применение при разработке проектов с использованием MVC Framework. Нами были подробно описаны составные части маршрутизации, применяемые в ней классы, интерфейсы и коллекции. Мы показали, как создавать маршруты, использовать таблицы маршрутизации, ограничения маршрутов и игнорирования маршрутов. В завершение главы нами были даны советы по использованию механизма маршрутизации, в том числе по организации модульного тестирования созданных маршрутов.

ГЛАВА 7

Ajax-функциональность

Последнее время все чаще и чаще слышны разговоры про Ajax. Появилось множество сайтов, использующих эту технологию, многие из них разработаны гигантами вроде Google или Microsoft. Ajax стал краеугольным механизмом для нового понятия Web 2.0. Так что же это такое — Ajax?

Ajax расшифровывается как Asynchronous JavaScript And XML, т. е. "асинхронный JavaScript и XML". Основное предназначение Ajax — осуществление запросов и получение данных для веб-страницы асинхронным способом, без перезагрузки самой страницы. Таким образом, пользователь не замечает запросы, посылаемые на сервер, а данные, передаваемые между сервером и клиентом, значительно уменьшаются в связи с тем, что пропадает надобность формировать и отправлять пользователю всю страницу целиком, по этой же причине снимается существенная нагрузка на сервер, которому нет нужды перестраивать страницу целиком или помещать ее в кэш.

Сама технология не нова, в той или иной мере она использовалась годами ранее, и только с широким распространением веб-сервисов появился специальный термин, который описывает не одну технологию, а подход к взаимодействию клиентского кода на стороне пользователя и бизнес-логике на сервере.

История успеха Ajax

Технология Ajax начала свою жизнь в середине 90-х годов. Когда вебтехнологии стали развиваться бурными темпами, появилась конкуренция браузеров и многие крупные компании старались внести свой вклад в создание будущего вида интернет-технологий. Так, компания Microsoft представила в 1996 году элемент iFrame, который позволял в одном окне браузера загружать данные из нескольких источников. Одним из применений iFrame стала незаметная для пользователя загрузка данных в скрытый фрейм с последующим использованием этих данных на основной странице. Можно сказать, что IFrame заложил некоторые основы Ajax, и даже сегодня данный подход широко используется на практике.

Чуть позднее компания Microsoft вновь внедрила инновационную технологию в свой браузер Internet Explorer, которая позволяла еще более просто асинхронно получать данные с сервера. Эта технология сегодня известна как объект XMLHttpRequest, который поддерживается всеми браузерами. Изначально XMLHttpRequest представлял собой ActiveX-компонент, который могли использовать разработчики, создающие свои продукты, нацеленные на работу в Internet Explorer. Этот компонент позволял при помощи JavaScript делать асинхронные запросы на сервер с получением данных в формате XML. Сама компания Microsoft использовала его в веб-версии почтового клиента Outlook.

Появление предка XMLHttpRequest можно считать рождением эры Web 2.0, хотя в то время ни такого термина, ни самого наступления новой эры никто не заметил. Потребовалось еще несколько лет, чтобы о технологии заговорили, и был даже придуман специальный термин. Значительное влияние на популяризацию и распространение технологии Ajax оказала компания Google, которая выпустила инновационные и сверхпопулярные в наше время проекты Gmail и Google Maps. Оба продукта Google не предлагали ничего нового: Gmail — это почтовый клиент, а Google Maps — сервис онлайн-карт, подобные которому уже существовали на рынке. Однако изменился сам подход и опыт использования приложений пользователем. Теперь вместо обязательных частых перезагрузок страницы при навигации по письмам или картографическому сервису пользователь получал интерфейс, который напоминал ему обычную настольную программу. Не было перезагрузок страницы с долгим ожиданием, вместо этого данные пользователя незаметно подгружались с сервера Google с использованием Ajax (рис. 7.1).

Пользователи очень быстро заслуженно оценили сервисы Google за их удобство, скорость работы и высокую отзывчивость. Кроме того, компания предложила беспрецендентный объем бесплатного почтового ящика в несколько гигабайт, но это уже другая история. Успех Gmail и Google Maps не прошел незамеченным, и технологией асинхронной передачи данных между браузером клиента и сервером стали интересоваться многие разработчики. Интерес к новому подходу при построении веб-сайтов все возрастал, все больше появлялось ресурсов, которые позволяли управлять собой без перезагрузок страницы, предлагая пользователю новый и интересный опыт общения с Интернетом.

В 2005 году Джейси Джеймс Гарретт, специалист по разработке пользовательских интерфейсов, придумывает специальный термин к технологии, которая уже заразила Интернет. Этим названием стал известный нам термин Ajax. В своей статье "Ajax: A New Approach to Web Applications" Гарретт описал как саму технологию, так и дал ей название. Ознакомиться с довольно объемной и подробной статьей можно и сегодня по адресу http://www.adaptivepath.com/ideas/essays/archives/000385.php. 18 февраля 2005 года, день выхода статьи, можно считать днем рождения старой технологии под новым именем, которое изменило представление об Интернете.

В апреле 2006 года консорциум W3C утвердил первый черновик стандарта, который описывал объект XMLHttpRequest. Это стало заключительным аккордом в широком распространении технологии Ajax, теперь основополагающая технология была стандартизирована, и ничто не мешало ее дальнейшему распространению.

Современный Ajax

В наше время уже трудно найти новые веб-проекты, которые бы не использовали технологию Ajax. Да и многие другие старые и заслуженные ресурсы также получают обновление сервисов с включением Ajax в той или иной мере. Например, вслед за появлением Gmail другой популярный сервис Hotmail также обзавелся Ajax-интерфейсом, за ними последовали многие другие почтовые онлайн-сервисы.

Применение Ajax находится повсюду, например, крупнейший социальный сервис с IT-тематикой Habrahabr.ru использует Ajax для препросмотра написанной статьи или комментария, для изменения рейтинга записей и пользователей. Другие популярные социальные сервисы вроде Facebook или Spaces предпочитают использовать Ajax для простых действий наподобие подтверждения пользователем своих действий или работы с данными других пользователей сети.

Еще одним интересным применением Ajax, которое предлагает пользователю новый опыт при использовании интерфейсов веб-приложений, стало извлечение данных по требованию. Так, например, Google Reader, популярный сервис для чтения RSS-каналов, позволяет с помощью скроллирования получать все новые и новые данные RSS-ленты, хотя предзагружена изначально лишь малая их часть. Подобный вариант, только более наглядный для пользователя, использует поисковой сервис Bing, в котором реализован "бесконечный" поиск по изображениям. Новые результаты поиска в виде набора изображений будут подгружаться по мере того, как пользователь скроллирует страницу все ниже и ниже (рис. 7.2).

Помимо простого влияния Ajax на современное представление о пользовательских интерфейсах, технология Ajax оказывает огромное влияние на интернет-индустрию в целом. Ajax вдохнул вторую жизнь в веб-сайты, многие из которых стали дублировать функционал, который ранее казался привязанным к десктопу. Появились ресурсы, которые позволяют редактировать офисные документы или изображения. Движение Rich Internet Applications, которое, как ранее казалось, будет осуществляться посредством плагинов и сторонних технологий вроде Flash или Silverlight, теперь вполне осуществимо стандартными веб-технологиями на основе браузера, HTML и JavaScript. Конечно, RIA на базе веб-технологий пока отстает по производительности и возможностям от технологий Flash/Silverlight, но многие задачи, которые ранее решались с помощью Flash, теперь можно решить на базе усиленного с помощью Ajax HTML-интерфейса.

Широкое распространение Ajax не могло пройти мимо инструментов разработчиков, и почти все они обзавелись поддержкой Ajax, с помощью которой работа с Ajax-запросами значительно упрощается. Такие Framework, как ExtJS, jQuery, MooTools и другие популярные инструменты для разработки JavaScript-кода, конечно, имеют поддержку Ajax. Об одном из таких инструментов пойдет речь и в этой главе. jQuery — популярнейший JS Framework содержит несколько инструментов для удобной работы с Ajax и, что очень важно, включен в состав Visual Studio и проект MVC Framework по умолчанию.

Пример использования Ajax

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

Первым делом мы должны создать экземпляр объекта XMLHttpRequest:

var xhr;

if (window.XMLHttpRequest)

{

xhr = new XMLHttpRequest();

}

else

if (window.ActiveXObject)

{

xhr = new ActiveXObj ect("Microsoft.XMLHTTP");

}

else

{

alert("Браузер не поддерживает XMLHttpRequest!");

}

Здесь в переменной xhr создается объект XMLHttpRequest. В зависимости от типа браузера доступ к этому объекту может быть разным. Старые версии Internet Explorer работают только через создание ActiveX-компонента. В Internet Explorer 7 и выше работа с XMLHttpRequest приведена к стандарту.

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

□ readyState = 0 — запрос не инициализирован;

□ readyState = 1 — запрос был установлен;

□ readyState = 2 — запрос был отправлен;

□ readyState = 3 — запрос происходит в данное время;

□ readyState = 4 — запрос завершен, получен результат.

Другое свойство responseText отвечает за хранение ответа от сервера после запроса. Если совместить использование всех этих свойств вместе, то можно написать следующий часто используемый код обработки асинхронного запроса:

xhr.onreadystatechange = function() {

if (xhr.readyState == 4) {

docum.ent.getElementById("timeText") .value = xhr.responseText;

}

}

Здесь свойству onreadystatechange присваивается функция для обработки изменения состояния объекта XMLHttpRequest, представленного переменной xhr. Функция проверяет свойство readyState на значение 4, которое говорит об успешном завершении запроса и присваивает элементу с идентификатором timeText текстовое значение результата запроса.

Для создания запроса к серверу используется две функции XMLHttpRequest: open и send. Функция open содержит три параметра:

□ текстовое значение с типом запроса: GET или POST;

□ текстовое значение со строкой запроса, указывающей на страницу, к которой необходимо выполнить запрос;

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

Функция send содержит один параметр, который должен определять данные, отправляемые вместе с запросом. Данные могут представлять собой как некую строку, так и XML-документ. В настоящее время чаще всего используется первый вариант, когда данные передаются в виде строки JSON-данных.

Для того чтобы отправить запрос на сервер, нужно вызвать следующий код:

xhr.open("GET","Home/GetTime",true);

xhr.send(null);

Запрос будет отправлен к ресурсу по относительному адресу Home/GetTime, когда сервер обработает запрос и пришлет ответ, в объекте xhr изменится состояние и будет вызвана наша реализация функции onreadystatechange.

Полный код примера, созданный на базе проекта MVC Framework по умолчанию, представлен в листинге 7.1.

Листинг 7.1

<%@ Page Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent"

runat="server">

Home Page

</asp:Content>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent"

runat="server">

<h2>

<%= Html.Encode(ViewData["Message"]) %>

</h2>

<p>

To learn more about ASP.NET MVC visit

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

</p>

<p>

<script type="text/javascript">

function GetTime() {

var xhr;

if (window.XMLHttpRequest) {

xhr = new XMLHttpRequest();

} else if (window.ActiveXObject) {

xhr = new ActiveXObj ect("Microsoft.XMLHTTP");

} else {

alert("Браузер не поддерживает XMLHttpRequest!");

}

xhr.onreadystatechange = function() {

if (xhr.readyState == 4) {

document.getElementById("timeText").innerHTML =

"Время на сервере: " + xhr.responseText;

}

}

xhr.open("GET", "Home/GetTime", true);

xhr.send(null);

}

</script>

<input type="button" onclick="javascript:GetTime()" value="Получить время" />

<span id="timeText">Время не получено</span>

</p>

</asp:Content>

В этом фрагменте кода создается кнопка для запроса данных с сервера, к которой привязан JavaScript-код Ajax и текстовое поле для отображения результата.

Серверный код, необходимый для работы, примитивен и представляет собой следующую реализацию действия GetTime для контроллера HomeController. Обратите внимание на использование атрибута OutputCache для предотвращения кэширования результата, которое в нашем случае не нужно:

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

public ActionResult GetTime()

{

return Json(DateTime.Now.ToString());

}

Запустив проект, мы можем запрашивать дату и время с сервера без перезагрузки страницы и с использованием технологии Ajax (рис. 7.3).

Мы рассмотрели принцип работы Ajax на базе XMLHttpRequest на простейшем примере. В действительности все несколько сложнее. Следует учитывать возможные ошибки, которые могут возникнуть при обработке запроса, необходимо обрабатывать истечение времени ожидания ответа от сервера. Для упрощения работы с Ajax существуют специальные библиотеки и Framework, про которые речь пойдет далее.

MVC Framework и Ajax

MVC Framework, как новый и современный инструмент, конечно, поддерживает Ajax и предлагает удобные и обширные средства по работе с ним. На самом деле MVC Framework содержит два отдельных Ajax-инструмента: стандартную библиотеку с классами-помощниками и библиотеку jQuery, одной из возможностей которой является упрощенная работа с Ajax.

Ajax-функционал в MVC Framework

В состав проекта MVC Framework по умолчанию входят два JavaScript-файла: MicrosoftAjax.js и MicrosoftMvcAjax.js, в которых для разработчиков предложены вспомогательные функции при работе с Ajax. Рассмотрим их по порядку:

□ MicrosoftAjax.js — основной файл, который содержит всю инфраструктуру ASP.NET для работы с Ajax. Эта библиотека может быть знакома тем, кто использовал Ajax.NET или AjaxControlToolkit в проектах на базе классического ASP.NET;

□ MicrosoftMvcAjax.js — файл, осуществляющий поддержку Ajax в MVC-проектах, код которых написан с помощью специальных вспомогательных методов. Эта библиотека использует MicrosoftAjax.js для своей работы.

Для упрощения работы с Ajax MVC Framework содержит кроме JavaScript-файлов еще и расширения в виде классов и методов .NET. Так, класс viewPage, по умолчанию базовый для всех страниц MVC-проектов, содержит свойство Ajax, которое является экземпляром класса AjaxHelper.AjaxHelper содержит перечисленные в табл. 7.1 вспомогательные методы для работы с Ajax в представлениях.

Чтобы использовать данные расширения в своих проектах, необходимо подключить оба JavaScript-файла, MicrosoftAjax.js и MicrosoftMvcAjax.js, на необходимую страницу либо для всех страниц сразу через файл master-страницы. Код для добавления ссылок на эти файлы в master-странице может быть следующим:

<head runat="server">

<script src="<%= Url.Content("~/Scripts/MicrosoftAjax.debug.js") %>"

type="text/javascript">

</script>

<script src="<%=Url.Content("~/Scripts/MicrosoftMvcAj ax.debug.js") %>"

type="text/javascript"></script>

</head>

Далее мы рассмотрим более подробно эти вспомогательные методы и еще один вспомогательный класс AjaxOptions и свойство IsAjaxRequest, также имеющие отношение к Ajax.

AjaxOptions

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

□ Confirm — задает текст, который будет выведен в запросе пользователю перед осуществлением запроса. Установка этого параметра приведет к тому, что перед запросом на сервер у пользователя будет возможность подтвердить отправку запроса или отменить ее (рис. 7.4);

Рис. 7.4. Запрос подтверждения при использовании параметра Confirm

□ HttpMethod — устанавливает тип HTTP-запроса (GET или POST), который будет использоваться при формировании асинхронного запроса. Может содержать одно из двух значений Get или Post, по умолчанию установлено в Post;

□ InsertionMode — свойство задает одно из значений одноименного перечисления InsertionMode: Replace, InsertBefore, InsertAfter. Значение по умолчанию Replace. Данное свойство устанавливает метод включения данных из ответа от сервера в элемент разметки: перезапись значения элемента, добавление до содержимого или после него. Данное свойство используется совместно со свойством UpdateTargetId, указывающим идентификатор элемента разметки, в которое будет записано значение результата ответа от сервера;

□ LoadingElementId — задает идентификатор элемента разметки, который должен быть отображен во время Ajax-запроса. Использование данного свойства приведет к тому, что указанный элемент будет показан во время запроса, а затем скрыт. Использование этого свойства имеет смысл для демонстрации пользователю анимации ожидания во время продолжительных запросов;

□ OnBegin — задает наименование JavaScript-функции, которая должна быть вызвана непосредственно перед отправкой асинхронного запроса на сервер;

□ Oncomplete — задает наименование JavaScript-функции, которая должна быть вызвана сразу после того, как запрос был завершен, и до того, как результат запроса был записан в элемент разметки. Не имеет значения, был ли завершен запрос удачно или нет, функция, указанная через Oncomplete, все равно будет вызвана. Данная функция будет вызвана до onFailure или onSuccess. Если требуется, чтобы результат не был записан в элемент разметки, то функция, указанная в Oncomplete, должна вернуть false;

□ OnFailure — задает наименование JavaScript-функции, которая должна быть вызвана в случае, когда асинхронный запрос завершился с ошибкой;

□ OnSuccess — задает наименование JavaScript-функции, которая должна быть вызвана в случае, когда асинхронный запрос завершился успешно;

□ updateTargetid — задает идентификатор элемента разметки, в который должен быть записан результат асинхронного запроса на сервер. Вместе с этим параметром может быть использован параметр InsertionMode, который указывает, каким именно способом должны быть записаны данные в элемент разметки;

□ url — устанавливает значение адреса сервера, куда следует отправить запрос. Свойство использовать не обязательно, когда класс AjaxOptions применяется в Ajax.BeginForm и Ajax.ActionLink, где действие и контроллер задают данные адреса. В случае если Url все же будет указан, он переопределит значения, определенные в этих методах.

Класс AjaxOptions и его свойства используются во вспомогательных методах Ajax.BeginForm и Ajax.ActionLink для тонкой настройки асинхронного запроса и его параметров, а также действий, осуществляемых в ответ на изменение состояния запроса. Например, в следующием фрагменте кода AjaxOptions используется для задания ряда параметров при вызове Ajax.ActionLink:

<p>

<script type="text/javascript">

function OnError() {

alert("Произошла ошибка!");

}

</script>

<%= Ajax.ActionLink("получить время", "GetTime", "Home",

new AjaxOptions() {

OnFailure="OnError",

Confirm="Bы уверены?",

UpdateTargetId = "timeText"

},

(object) null)

%><br/>

<span id="timeText">Нажмите на ссылку для получения времени<^span>

</p>

Ajax.BeginForm

Вспомогательный метод Ajax.BeginForm, в зависимости от реализации, содержит набор из следующих параметров:

□ actionName — указывает наименование действия, которое следует вызвать в запросе, в случае, когда используется вариант метода без указания контроллера, вызывается действие контроллера текущего контекста;

□ controllerName — указывает наименование контроллера (сокращенное, без суффикса Controller), в котором следует искать и вызвать указанное в параметре actionName действие;

□ routeValues — указывает объект, содержащий параметры для механизма маршрутизации;

□ ajaxOptions — указывает экземпляр класса AjaxOptions с заданными свойствами, которые определяют параметры асинхронного запроса и могут определять ряд JavaScript-функций, реагирующих на изменение состояния запроса;

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

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

<% using(Aj ax.BeginForm("LoginForm",

new AjaxOptions{UpdateTargetId="loginStatus"})) {

%>

<dl>

<dt>

<span id="loginStatus">Введите логин и пароль, чтобы продолжить.</span>

</dt>

<dt>Введите логин:</dt>

<dd><%= Html.TextBox("login")%></dd>

<dt>Введите пароль:</dt>

<dd><%= Html.TextBox("password")%></dd>

<dt><input type="submit" value="Войти"/></dt>

</dl>

<% } %>

Здесь с помощью вспомогательного метода Ajax.BeginForm создается стандартная форма авторизации с двумя текстовыми полями для ввода логина и пароля и кнопкой отправки данных. Обратите внимание на параметры Ajax.BeginForm: во-первых, указывается LoginForm — наименование действия, которое должно вызваться в ответ на отправку данных с формы, во-вторых, с помощью класса AjaxOptions задается специальный параметр UpdateTargetId, который указывает на элемент, ответственный за отображение результата запроса. То есть, если запрос вернет данные, они будут отображены, в нашем случае, с помощью элемента span с идентификатором loginStatus.

Как можно заметить, создание всего Ajax-функционала не потребовало у нас ни строчки JavaScript, не требуется от нас и понимание различий реализаций поддержки Ajax разными браузерами. Все это скрытно реализуют библиотеки MicrosoftAjax.js и MicrosoftMvcAjax.js, делая за разработчика всю рутинную работу по организации работы с асинхронными запросами. Если мы взглянем на исходный код, который сгенерирует подсистема Ajax в MVC Framework для нашего кода, то сможем убедиться, что генерируется достаточно много автоматического кода. Далее представлено определение формы, которое создано автоматически для нашего примера:

<form action="/Home/LoginForm" method="post"

onclick="Sys.Mvc.AsyncForm.handleClick(this, new Sys.UI.DomEvent(event));"

onsubmit="Sys.Mvc.AsyncForm.handleSubmit(this,

new Sys.UI.DomEvent(event), {

insertionMode:Sys.Mvc.InsertionMode.replace,

updateTargetId:'loginStatus'

});">

Как можно видеть, вызов Ajax.BeginForm сгенерировал код для функционала, который предлагают библиотеки MicrosoftAjax.js и MicrosoftMvcAjax.js.

Ajax.ActionLink

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

□ linkText — текст, который будет рендериться в виде значения гиперссылки;

□ actionName — указывает наименование действия, которое следует вызвать в запросе, в случае, когда используется вариант метода без указания контроллера, вызывается действие контроллера текущего контекста;

□ controllerName — указывает наименование контроллера (сокращенное, без суффикса Controller), в котором следует искать и вызвать указанное в параметре actionName действие;

□ protocol — указывает используемый для формирования ссылки протокол  http или https;

□ hostName — указывает значение хоста, которое будет использовано для формирования ссылки;

□ fragment — указывает значение якоря, которое будет использовано для формирования ссылки. Это значение используется браузером для навигации по странице и обычно представляет собой значение идентификатора какого-либо элемента разметки, к которому следует выполнить навигацию. Данное значение будет добавлено к ссылке в следующем виде: http://localhost/Home/GetTime#fragment;

□ routeValues — указывает объект, содержащий параметры для механизма маршрутизации;

□ ajaxOptions — указывает экземпляр класса AjaxOptions с заданными свойствами, которые определяют параметры асинхронного запроса и могут определять ряд JavaScript-функций, реагирующих на изменение состояния запроса;

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

Применение ActionLink еще проще, рассмотрим его использование на примере получения даты и времени для отображения на странице:

<%= Ajax.ActioriLink(''Пaлучить время", "GetTime", "Home",

new AjaxOptions() { UpdateTargetId = "timeText" },

(object) null) %><br />

<span id="timeText">Нажмите на ссылку для получения времени<sрап>

Здесь с помощью вспомогательного метода Ajax.ActionLink создается ссылка, которая с помощью Ajax.NET скрытно связывается с асинхронным запросом на сервер. Кроме текста ссылки, наименования действия и контроллера, в функцию передается набор параметров AjaxOptions, в котором, в нашем случае, параметр UpdateTargetId устанавливается равным идентификатору элемента, где будет отображен результат запроса. В последний параметр, который определяет значение атрибутов HTML-элемента, передается значение (object) null, чтобы указать, что никаких дополнительных HTML-атрибутов рендерить не нужно.

Как и в случае использования Ajax.BeginForm, при рендеринге Ajax.ActionLink незаметно для разработчика создается вспомогательный код, который реализует весь Ajax-функционал, избавляя разработчика от написания рутинного кода:

<a href="/Home/GetTime?Length=4"

onclick="Sys.Mvc.AsyncHyperlink.handleClick(this,

new Sys.UI.DomEvent(event),

{

insertionMode: Sys.Mvc.InsertionMode.replace, updateTargetId: 'timeText'

});">Получить время</a>

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

IsAjaxRequest

Метод IsAjaxRequest является методом расширения для класса HttpRequestBase. Данный метод возвращает булево значение, которое сообщает, является ли текущй запрос Ajax-запросом или нет. IsAjaxRequest может быть полезен тогда, когда ваше действие меняет логику в зависимости от типа запроса. Например, в следующем примере представлена реализация действия, в котором в зависимости от типа запроса возвращается либо набор данных, либо данные с готовой HTML-разметкой:

public ActionResult GetTime()

{

if (Request.IsAjaxRequestO)

{

return Json(DateTime.Now.ToString());

} else

return View(DateTime.Now.ToString());

}

jQuery

С недавних пор jQuery стала частью пакета Visual Studio. В среде разработчиков, работающих с JavaScript, jQuery зарекомендовала себя очень хорошо, и разработчики пакета Visual Studio решили не изобретать свой вариант JavaScript-библиотеки для работы с селекторами и DOM-моделью документа, когда встал такой вопрос, а взять готовый мощный отлаженный и знакомый многим разработчикам инструмент.

Одна из самых главных возможностей, которую предлагает jQuery, — это написание JavaScript-кода для работы с объектной моделью документа, основанного на селекторах CSS3. Селекторы CSS3 — это возможность назначить CSS-стиль не просто отдельному элементу в документе по его классу или идентификатору, но выбрать целый ряд элементов согласно некому общему признаку. Например, следующий CSS-код устанавливает стиль всем вложенным элементам li относительно элементов с классом . list:

.list > li {

color: #FFFFFF;

}

CSS-селекторы содержат гибкие варианты и операторы для доступа к элементам DOM для самых различных сценариев. Поддержка CSS-селекторов библиотекой jQuery означает, что вы получаете возможность проще выбирать часть объектов модели документа, используя знакомый CSS-синтаксис и минимум кода.

Примечание

Описание CSS-селекторов выходит за рамки этой статьи. Достаточно сказать лишь, что это важнейший и мощный инструмент по работе с DOM-моделью документа, и jQuery позволяет работать с dom на базе набора последней, третьей версии CSS-селекторов.

*********************************

Библиотека jQuery представлена в Visual Studio двумя JS-файлами: jquery-1.3.1js и jquery-1.3.1.min.js (на момент написания книги). Эти файлы идентичны по функционалу и отличаются только тем, что второй вариант минимизирован, т. е. текст его максимально оптимизирован для уменьшения размера (убраны переносы, лишние пробелы и выполнены другие оптимизации). Обычно первый вариант библиотеки используют при разработке и отладке, поскольку, кроме читаемого кода, библиотека содержит массу полезных комментариев. Второй вариант, специально уменьшенный, используется уже на реальном применении.

Для упрощения работы с библиотекой Visual Studio содержит специальные файлы *- vsdocjs, которые необходимы для поддержки IntelliSense при работе с функциями и свойствами jQuery. Чтобы использовать эти файлы, вам необходимо иметь Visual Studio 2008 с первым сервис-паком и установленным обновлением VS90SP1-KB958502-x86. Если у вас установлено это обновление, то после подключения скрипта jQuery к странице через тег script, вы получите возможность работать с функциями и свойствами библиотеки jQuery с помощью IntelliSense (рис. 7.5).

jQuery содержит ряд фукций по работе с Ajax, перечислим их и приведем основное назначение:

□ jQuery.ajax — выполняет Ajax-запрос на сервер;

□ load — выполняет Ajax-запрос на сервер и вставляет результат в DOM страницы;

□ jQuery.get — упрощенная версия jQuery.ajax, которая позволяет посылать GET-запросы на сервер с помощью Ajax;

□ jQuery .getJSON — версия jQuery.get, которая загружает с сервера данные в формате JSON с помощью Ajax-запросов;

□ jQuery.getscript — загружает с помощью Ajax текст JavaScript-кода и исполняет его;

□ jQuery.post — загружает данные с сервера с использованием Ajax и POST-запроса.

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

Рассмотрим использование jQuery на примере решения знакомой нам задачи с выводом текущей даты и времени на сервере с помощью Ajax-запроса. Для этого перепишем функцию GetTime из предыдущей JavaScript-реализации на jQuery:

<script type="text/javascript">

function GetTime() {

$.get("Home/GetTime", null, function(result) {

$('#timeText').text('Bpeмя на сервере: ' + result);

}, "text")

}

</script>

Сравните JavaScript-реализацию без вспомогательных библиотек с 20 строками и jQuery с шестью. Разница очевидна: использование jQuery не требует ни организации поддержки всех браузеров, ни обработки получения результата и состояния запроса. Все это низкоуровневое взаимодействие jQuery берет на себя. В приведенном примере использована функция jQuery $.get ($ — это синоним объекта jQuery). В функцию get передаются следующие параметры:

□ строка с адресом запроса;

□ null — как значение данных, передаваемых на сервер;

□ функция обратного вызова, которая будет вызвана в случае завершения запроса;

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

Очевидно, что использование jQuery способно существенно сократить время, требующееся на создание клиентского кода, в том числе для реализации Ajax-функционала.

MVC Framework содержит все необходимое для поддержки разработчиков в их стремлении делать современные веб-проекты с использованием технологий Ajax. Включенная во Framework библиотека jQuery позволяет работать с клиентским кодом и JavaScript и гораздо проще организовывать Ajax-запросы. Встроенные средства MVC Framework и AJAX.NET позволяют вывести работу с Ajax на новый уровень абстракции, который позволяет меньше заботиться о написании JavaScript и дает возможность разработчику сосредоточиться на решении задачи вместо того, чтобы организовывать низкоуровневые взаимодействия между разметкой и асинхронными запросами к серверу.

Библиотека jQuery

jQuery — это сторонняя для Visual Studio JavaScript-библиотека, которую разработал Джон Ресиг, евангелист организации Mozilla Foundation, которая выпускает популярный браузер Firefox. Библиотека jQuery была выпущена в начале 2006 года и очень быстро завоевала популярность среди разработчиков в связи со своей простотой и в то же время чрезвычайно сильными возможностями. Ее основное назначение — это упрощенная работа с DOM-элементами документа. Библиотека так построена, что в JavaScript стало возможным использовать для выборки и работы с элементами HTML-страницы селекторы, соответствующие CSS3-селекторам. Это позволяет значительно упростить работу с HTML, создание анимации и динамического изменения разметки.

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

Кроме работы с DOM, библиотека jQuery имеет встроенные средства для упрощения работы с Ajax. jQuery берет на себя всю работу по унификации доступа к функционалу Ajax в разнообразных браузерах и предлагает разработчику несколько своих полезных функций. В отличие от вспомогательных Ajax-методов MVC Framework, работа с Ajax в jQuery не может обходиться без написания JavaScript-кода.

jQuery API

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

Здесь мы рассмотрим все функции и события Ajax, имеющиеся в библиотеке и составляющие API jQuery по работе с асинхронными запросами. В табл. 7.2 приведен список функций Ajax-подсистемы в jQuery.

Функции для работы с Ajax

jQuery.ajax

Функция предназначена для организации Ajax-запросов и представляет собой самый активный элемент jQuery API, но в то же время самый низкоуровневый. jQuery.ajax принимает один-единственный параметр — структуру данных, которая описывает все, что необходимо для организации асинхронного запроса. Структура данных может содержать следующие поля:

□ async — булево значение, определяющее, будет ли запрос асинхронным. По умолчанию async=true;

□ beforeSend — определяет функцию, которая будет вызвана перед отправкой асинхронного запроса. Этой функции передается единственный параметр текущий объект XMLHttpRequest;

□ cache — позволяет управлять кэшированием страниц, по умолчанию установлено cache=true;

□ complete — определяет функцию, которая вызывается в момент завершения запроса, в том числе в случае неудачного запроса. В функцию передается два параметра: текущий объект XMLHttpRequest и строка, которая указывает статус завершения запроса;

□ contentType — определяет строковое значение типа данных запроса (HTTP-заголовок content-type). По умолчанию значение устанавливается в application/x-www-form-urlencoded;

□ data — данные, представленные объектом или строкой, которые должны быть отправлены на сервер вместе с запросом;

□ dataFilter — определяет функцию, которая вызывается для полученных в результате запроса данных. Подразумевается, что данная функция проведет проверку данных и приведет их в безопасный для использования на стороне клиента вид. Функция принимает два параметра: собственно принятые с сервера данные и строковое значение типа данных;

□ dataType — строка, определяющая тип данных, который ожидается в результате запроса. В зависимости от некоторых условий по умолчанию значение этого параметра устанавливается в "xml" или "html";

□ error — определяет функцию, которая будет вызвана в случае возникновения какой-либо ошибки при выполнении асинхронного запроса. Функция принимает три параметра: текущий объект XMLHttpRequest, строку с описанием типа ошибки и опциональный объект с описанием исключения, если оно было вызвано;

□ global — булево значение, которое определяет, должно ли выполнение этого запроса быть глобальным, что приводит к реагированию на него функций, или вызов не должен вызывать глобальные события. По умолчанию global=true;

□ ifModified — булево значение, которое указывает, что запрос должен считаться только тогда, когда возвращенные данные отличаются с момента прошлого запроса. По умолчанию ifModified=false;

□ password — строка, содержащая пароль, который будет использован в случае, когда производится запрос с обязательной аутентификацией;

□ processData — булево значение, которое определяет, необходимо ли производить обработку отправляемых данных из объектного представления в строковое. По умолчанию установлено processData=true;

□ success — определяет функцию, которая будет вызвана в случае, если запрос успешно завершится. Функция принимает два параметра: объект, содержащий полученные от сервера данные, и строковое значение, указывающее статус результата запроса;

□ timeout — числовое значение, которое определяет время ожидания ответа от сервера, по истечении которого запрос будет считаться завершившимся с ошибкой;

□ type — строка, определяющая типа запроса (GET или POST), по умолчанию type="GET";

□ url — строка, определяющая адрес, к которому отправляется запрос. По умолчанию подразумевается текущая страница;

□ username — строка, определяющая имя пользователя, которое будет использовано в случае, когда производится запрос с обязательной аутентификацией;

□ xhr — определяет функцию, которая должна создавать объект XMLHttpRequest. По умолчанию функция создает такой объект через ActiveXObject, если это возможно, если нет, то используется объект XMLHttpRequest. Вы можете переопределить эту функцию для собственной реализации создания объекта XMLHttpRequest.

Как можно заметить, функция jQuery.ajax обладает очень большим количеством настроек. Однако, в связи с тем, что практически все они имеют значения по умолчанию, использование jQuery.ajax не представляет собой особой сложности. Так, далее представлен вариант запроса значения даты и времени с сервера с помощью jQuery.ajax:

<script type="text/javascript">

function GetTime() {

$.ajax({

url: 'Home/GetTime',

success: function(result) {

$('#timeText').text('Bpeмя на сервере: ' + result);

},

dataType: 'text'

});

}

</script>

При всем перечисленном количестве возможных параметров для функции jQuery.ajax использование ее не вызывает труда. Достаточно указать всего лишь три параметра: адрес, обработчик результата и ожидаемый тип результата. Этого достаточно в нашем случае для простейшего асинхронного запроса.

load

Данная функция применяется для уже готового результата селектора jQuery и предназначена для того, чтобы запросить с сервера HTML-код и внедрить его в выбранные ранее объекты. Функция содержит три параметра:

□ url — строка адреса для запроса на сервер. Данная строка может содержать любой допустимый селектор для фильтрации результатов запроса. Например, строка "Home/GetTime span.timeData" отправит запрос по адресу Home/GetTime, но результат запроса будет отфильтрован — из него будет выбран элемент (или элементы) span с CSS-классом timeData;

□ data (необязательно) — параметры запроса, которые следует отправить на сервер. Параметры могут быть представлены в двух видах. В первом случае, когда параметр представлен в виде строки, формируется GET-запрос. Во втором случае, когда параметры представлены в виде объектов и пар "ключ/значение", формируется POST-запрос;

□ callback (необязательно) — определяет функцию, которая будет вызвана после завершения запроса, удачного либо нет. Функция содержит три параметра: текст ответа, тип данных ответа и объект XMLHttpRequest.

Следующий пример загрузит значение времени в элемент с индентификатором timeText:

<script type="text/javascript">

function GetTime() {

$('#timeText').load('Home/GetTime');

}

</script>

Как можно убедиться, асинхронный запрос и изменение значения элемента HTML-разметки уместилось всего в одной строке. Это крайне удобно в ряде случаев.

jQuery.get и jQuery.post

Данные функции являются упрощенными и более высокоуровневыми вариантами функции jQuery.ajax. Каждая из функций принимает четыре параметра:

□ url — строка адреса для запроса на сервер;

□ data (необязательно) — данные для отправления на сервер;

□ callback (необязательно) — определяет функцию, которая вызывается после завершения выполнения асинхронной операции;

□ type (необязательно) — строка, определяющая тип ожидаемых данных с сервера. Может принимать одно из следующих значений: "xml", "html", "script","json", "jsonp" или "text".

Применение этих функций вместо более комплексной jQuery.ajax оправдано в большинстве случаев. Различие между jQuery.get и jQuery.post только одно: первая выполняет GET-запрос, вторая — POST.

jQuery. getJSON

Функция jQuery.getJSON предназначена для упрощения работы с данными в формате JSON и получения их через Ajax. jQuery.getJSON поддерживает также работу с JSONP. Функция содержит три знакомых нам параметра:

□ url — строка адреса для запроса на сервер. Для сайтов, которые поддерживают JSONP, в этом параметре можно указать параметр callback=?, чтобы иметь возможность обратиться с Ajax-запросом к домену, отличному от текущего домена сервера;

□ data (необязательно) — параметры, которые необходимо отправить на сервер;

□ callback (необязательно) — определяет функцию, которая должна быть вызвана после завершения запроса.

Использование jQuery.getJSON оправдано в случаях, когда реализуется взаимодействие с сервером, в котором достоверно известно, что обмен данными будет производиться только на базе формата JSON.

jQuery.getScript

Функция jQuery.getScript предназначена для асинхронных запросов, результатами которых являются JavaScript-фрагменты кода. После получения такого фрагмента jQuery.getScript выполняет полученный код. Функция содержит всего два параметра:

□ url — строка адреса для запроса на сервер;

□ callback (необязательно) — определяет функцию, которая должна быть вызвана после завершения запроса, загрузки и выполнения JavaScript-фрагмента.

Использование jQuery.getScript не является самым распространенным вариантом асинхронных запросов. Однако эта функция может быть полезна в тех случаях, когда требуется динамически подгружать JavaScript-функционал.

jQuery. ajaxSetup

Функция jQuery.ajaxSetup не является функцией, которая взаимодействует с сервером или занимается посылкой данных. Вместо этого jQuery.ajaxSetup предназначена для инициализации параметров, используемых по умолчанию при вызовах jQuery.ajax. Функция принимает только один параметр: options — структура данных, которая описывает все, что необходимо для организации асинхронного запроса. Возможные параметры структуры и их значения описаны вместе с описанием функции jQuery.ajax.

Например, чтобы изменить поведение по умолчанию для jQuery.ajax, чтобы вместо GET-запросов по умолчанию производились POST-запросы, необходимо вызвать следующий код:

$.ajaxSetup({ type: "POST" });

После этого все вызовы jQuery.ajax по умолчанию будут создавать POST-запросы. jQuery.ajaxSetup крайне полезна для инициализации сценария клиентской страницы, когда вместо того, чтобы передавать однотипные параметры с каждым вызовом jQuery.ajax, вы определяете их как значения по умолчанию.

События Ajax в jQuery

Помимо функций, работающих с Ajax, в библиотеке jQuery существует ряд функций, добавляющих обработчиков к событиям, которые также относятся к сфере Ajax и вызываются в тот или иной момент работы Ajax-запросов:

□ ajaxComplete — событие, возникающее в момент завершения Ajax-запроса. Результат завершения не влияет на возникновение события. ajaxComplete будет вызвано в любом случае: был ли запрос успешен, произошла ли ошибка, исключительная ситуация или время ожидания ответа от сервера истекло;

□ ajaxError — событие, возникающее в момент завершения Ajax-запроса с ошибкой. Событие ajaxError позволяет обработать исключительную ситуацию, возникшую при выполнении запроса на сервере, или другие ситуации, когда запрос не был успешно выполнен;

□ ajaxSend — событие, возникающее непосредственно перед отправкой запроса на сервер. Событие ajaxSend часто используется для изменения состояния пользовательского интерфейса, например, для запрещения элементов, с помощью которых может быть отправлен повторный запрос. Кроме того, разработчик может использовать событие ajaxSend для отображения сообщения для пользователя о том, что запрос был отправлен на сервер;

□ ajaxstart и ajaxstop — однотипные события, которые возникают в момент старта и остановки Ajax-запросов соответственно. Могут быть использованы точно так же, как ajaxsend или ajaxComplete, однако отличаются от них отсутствием параметров с дополнительными данными;

□ ajaxSuccess — событие, возникающее в момент успешного завершения Ajax-запроса. Если Ajax-запрос был выполнен успешно и были получены данные от сервера, то вызывается событие ajaxSuccess, обработав которое разработчик может отреагировать на успешный асинхронный запрос.

Все эти события могут быть обработаны пользовательскими функциями, в которые передается от одного до четырех параметров. Не принимают параметры только функции, обрабатывающие события ajaxstart и ajaxstop. Следующие параметры используются во всех остальных функциях:

□ event — объект, содержащий информацию о событии;

□ XMLHttpRequest — объект, содержащий информацию о запросе;

□ ajaxOptions — параметры, которые были использованы для запроса.

Событие ajaxError, кроме перечисленных трех, содержит четвертый параметр:

□ thrownError — объект, который содержит информацию о произошедшей ошибке.

Использовать данные события достаточно просто. Рассмотрим пример, который выводит пользователю сообщение о старте Ajax-запроса, скрывает кнопку, для предотвращения повторного запроса, и возвращает ее после того, как запрос выполнился. Для этого модифицируем код функции GetTime и разметку так, как представлено в следующем фрагменте:

<script type="text/javascript">

function GetTime() {

$('#requestStatus').ajaxStart(function() {

$(this).text('Запрос запушен...');

$('#ajaxSend').hide();

});

$('#requestStatus').ajaxStop(function() {

$(this).text('Запрос завершен...');

$('#ajaxSend').show();

});

$.get('Home/GetTime',

null,

function(result) {

$('#timeText').text('Bpeмя на сервере: ' + result);

});

}

</script>

<span id="requestStatus">Нажмите кнопку для 3anpoca</span><br/>

<input id="ajaxSend"

type="button"

onclick="javascript:GetTime()"

value="Получить время" />

<span id="timeText">Время не получено</span>

Здесь представлена разметка для элемента requestStatus с отображением статуса Ajax-запроса, кнопки ajaxSend и элемента timeText для отображения результата запроса. В JavaScript-коде определены две функции для обработки ajaxStart и ajaxStop, которые отображают статус текущего состояния запроса и скрывают или показывают кнопку в зависимости от состояния. Для более явной демонстрации действия событий jQuery добавим в функцию GetTime контроллера HomeController задержку выполнения, чтобы увидеть, как изменяется сообщение о статусе запроса:

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

public ActionResult GetTime()

{

Thread.Sleep(1000);

return Json(DateTime.Now.ToString());

}

Теперь, если пользователь нажмет кнопку Получить время, состояние запроса будет выведено в специальном поле (рис. 7.6). После получения результата поле состояния соответственно изменится (рис. 7.7).

Мы рассмотрели jQuery API, которое позволяет значительно упростить работу с Ajax-запросами как в целом, так и для частых практических ситуаций. Как мы убедились, некоторые варианты использования Ajax в jQuery могут состоять всего из одной строки текста. В следующей части главы мы рассмотрим применение jQuery более подробно.

Применение Ajax и jQuery в MVC Framework

Рассмотрим применение инструментов Ajax в MVC Framework на конкретных примерах. Для этого реализуем несколько простых сценариев в проекте MVC Framework по умолчанию. Чтобы охватить как можно больше, реализация будет выполнена в двух вариантах: с помощью ASP.NET Ajax и с помощью jQuery.

Пример 1. Проверка логина при регистрации

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

Первоначально создадим действие Checkusername в контроллере Accountcontroller для реализации проверки на наличие имени пользователя на сайте. Далее представлен код метода checkusername, который принимает один строковый параметр username:

public ActionResult CheckUsername(string username)

{

string result;

if (String.IsNullOrEmpty(username))

{

result = "не указано имя пользователя";

}

else

{

var users = Membership.FindUsersByName(username);

result = users.Count > 0 ?

"такой пользователь уже существует" :

"ваше имя пользователя не занято";

}

return Json(result);

}

Данный метод принимает параметр с именем пользователя для проверки существования регистрации пользователя с таким именем. Метод CheckUsername возвращает строковое представление результата проверки.

Для вызова этого метода необходимо создать соответствующую разметку.

Реализация на ASP.NET Ajax

Добавим в Register.aspx ссылку для проверки введенного логина на наличие плюс поле для вывода результата проверки:

<label for="username">Username:</label>

<%= Html.TextBox("username") %>

<%= Html.ValidationMessage("username") %>

<%= Ajax.ActionLink("Пpoверить доступность логина",

"CheckUsername",

new AjaxOptions {OnBegin ="CheckUsername_OnBegin"

, UpdateTargetld =

"check_username"}

)

%>

<span id="check_username"></span>

Здесь с помощью вспомогательного метода Ajax.ActionLink создается гиперссылка для вызова действия CheckUsername. C помощью создания структуры типа AjaxOptions мы задаем несколько параметров. Во-первых, мы задаем функцию CheckUsername_OnBegin, которая должна быть вызвана перед запросом, а во-вторых, указываем тег с идентификатором check_username, который должен быть использован для рендеринга результата.

К сожалению, базовый функционал ASP.NET Ajax пока не поддерживает возможность задавать динамические параметры для запросов, формируемых через Ajax.ActionLink. Поэтому, чтобы передать с запросом введенные пользователем данные, нам нужно обработать начало запроса и сформировать самостоятельно URL запроса с необходимой строкой параметров. Чтобы сделать это, мы задали функцию CheckUsername_OnBegin, код которой выглядит так:

<script type="text/javascript">

function CheckUsername_OnBegin(data) {

var username = document.getElementById("username").value;

var request = data.get_request();

var url = request.get_url();

url = url + "?username=" + username;

request.set_url(url);

}

</script>

Здесь производится получение URL запроса и формирование нового URL на базе введенных пользовательских данных. Последней строкой скрипта новый URL устанавливается для Ajax-запроса.

В итоге после компиляции на странице регистрации мы сможем увидеть рядом с полем ввода имени пользователя ссылку для проверки на допустимость такого логина (рис. 7.8). После нажатия кнопки пользователь получает результат проверки в виде строки сообщения (рис. 7.9).

Рис. 7.8. Форма регистрации с гиперссылкой на проверку доступности логина

Реализация на jQuery

Посмотрим, насколько реализация проверки на наличие логина на jQuery отличается от описанной ранее реализации на ASP.NET Ajax. Во-первых, определим гиперссылку для проверки логина пользователя:

<label for="username">Username:</label>

<%= Html.TextBox("username") %>

<%= Html.ValidationMessage("username") %>

<a id="checkUsername" href="#">Проверить доступность логина</а>

<span id="check_username"></span>

Как можно заметить, определение гиперссылки является простым определением разметки, которая ничем не отличается от обычной. Основная работа ложится на код JavaScript, который представлен далее:

<script type="text/javascript">

$(document).ready(function() {

$("#checkUsername").bind("click",

function() {

var username = $("#username").val();

$("#check_username")

.load("/Account/CheckUsername?username=" + username);

})

});

</script>

Здесь мы объявляем глобальный обработчик, который выполнится после загрузки документа $(document).ready (...). В этом обработчике мы задаем поведение для обработки нажатия пользователя на необходимую нам ссылку с идентификатором $("#checkUsername").bind("click", ...). В самом обработчике нажатия производятся следующие действия: получается значение введенного пользователем логина и с помощью функции load производится запрос на сервер для проверки пользовательских данных.

Нетрудно заметить, что в случае с jQuery нам пришлось произвести меньше действий. Во-первых, вместо определения серверного кода с определением Ajax.ActionLink мы сформировали с помощью HTML-разметки обыкновенную ссылку. Во-вторых, для передачи параметра с пользовательскими данными в случае jQuery нам не пришлось работать с внутренними объектами ASP.NET Ajax, вместо этого мы работали со ссылкой напрямую, сформировав ссылку для запроса обыкновенным сложением строк. И в-третьих, само количество кода для jQuery оказалось меньшим, чем потребовалось написать кода для ASP.NET Ajax.

Примечание

Следует заметить, что передача на сервер пользовательского ввода всегда сопряжена с опасностью. Злоумышленник может ввести в виде текста опасный код, например кусок SQL-кода или JavaScript-кода, который затем, в случае когда не проводится проверка пользовательского ввода, будет исполнен вашим сервером или браузером на компьютерах ваших пользователей. Чтобы избежать этого, необходимо всегда обрабатывать пользовательский ввод и учитывать его потенциальную опасность.

***********************************

Пример 2. Логин через Ajax

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

Первоначально переопределим действие LogOn в контроллере Account так, чтобы поддержать возможность произведения входа в систему черезе Ajax-запросы (листинг 7.2).

Листинг 7.2. Переопределение действия LogOn

public ActionResult LogOn(string userName,

string password,

bool rememberMe,

string returnUrl)

{

if (Request.IsAjaxRequest())

{

var result = new AjaxResult();

if (!ValidateLogOn(userName, password))

{

result.IsSuccess = false;

result.ErrorString = "введен неверный логин или пароль";

return Json(result);

}

FormsAuth.SignIn(userName, rememberMe);

result.IsSuccess = true; return Json(result);

}

else

{

if (!ValidateLogOn(userName, password))

{

return View();

}

FormsAuth.SignIn(userName, rememberMe);

if (!String.IsNullOrEmpty(returnUrl))

{

return Redirect(returnUrl);

}

else

{

return RedirectToAction("Index", "Home");

}

}

}

Обратите внимание на выделенный в листинге 7.2 фрагмент. В нем используется метод Request.IsAjaxRequest() для определения типа запроса. Если запрос был произведен с помощью Ajax, то выполнятся дальнейшая обработка и возврат результата в виде JSON-данных с булевым значением, описывающим, произведен ли вход в систему, и строкой описания ошибки, если она возникла. Когда запрос не является Ajax-запросом, выполняется предыдущая логика.

Реализация на ASP.NET Ajax

Сделаем так, чтобы вход в систему был возможен на любой странице проекта (рис. 7.10). Для этого добавим разметку, необходимую для отображения элементов управления входа в систему, в элемент управления LogOnUserControl.ascx:

<% if (Request.IsAuthenticated) { %>

Welcome <b><%= Html.Encode(Page.User.Identity.Name) %></b>!

[ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]

<% } else { %>

<div id="loginPanel">

<% using(Ajax.BeginForm("LogOn", "Account",

(object) null,

new AjaxOptions{OnSuccess = "OnLogon",

OnFailure = "OnError"})) {%>

Логин: <%= HtmL.TextBoxC'userNams'') %>

Пароль: <%= Html.Password ("password") %>

<%= HtmL.CheckBox("RememberMe") %> запомнить <input type^'submit" vaLue="Логин" /><br/>

<span id="message"></span>

<% } %>

</div>

<p id="logoutPanel" style="display: none;">

Welcome <b><span id="username"></span></b>!

[ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]

</p>

<% } %>

Здесь в выделенном фрагменте кода с помощью вспомогательного метода Ajax.BeginForm объявляется форма для ввода данных. Устанавливаются параметры формы: действие, контроллер, которые требуется вызвать. С помощью определения экземпляра AjaxOptions определяются параметры Ajax-запроса: при успешном запросе будет вызвана JavaScript-функция onLogon, при возникновении ошибки будет вызваана другая функция — onError. Определим логику этих JavaScript-функций, которые будут реагировать на результат Ajax-запросов (листинг 7.3).

Листинг 7.3. JavaScript-код для реагирования на события

<script type="text/javascript">

function OnLogon(result) {

var response = result.get_response();

var resString = response.get_responseData();

var resultData = Sys.Serialization

.JavaScriptSerializer.deserialize(resString) ;

if (resultData.IsSuccess) {

document.getElementById('loginPanel').style.display = 'none';

document.getElementById('logoutPanel').style.display = '';

var username = document.getElementById('userName');

document.getElementById('username')

.innerHTML = "<b>" + username.value + "</b>";

} else {

document.getElementById('message')

.innerText = resultData.ErrorString;

}

}

function OnError(result) {

alert(result);

}

</script>

Здесь определяются две JavaScript-функции: OnLogon и OnError. Первая функция предназначена для обработки результата успешного выполнения авторизации. Функция OnLogon принимает один параметр — result, который содержит результат выполнения запроса и дополнительные данные. Для получения JSON-данных, которые были получены от действия LogOn, в функции OnLogon используются сужебные функции ASP.NET Ajax:

□ get_response — возвращает объект с данными ответа от сервера;

□ get_responseData — позволяет получить строку данных, которые были возвращены действием контроллера;

□ Sys.Serialization.JavaScriptSerializer.deserialize — преобразует строку с JSON-данными в объект с соответствующими полями.

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

Реализация на jQuery

Для реализации поставленной задачи с помощью jQuery необходимо определить следующую разметку элементов управления:

<div id="loginPanel">

<form id="loginForm" method="post" action="Account/LogOn">

Логин: <input id="userName" type="text" />

Пароль: <input id="password" type="password" />

<input id="RememberMe" type="checkbox" />

запомнить <input type="submit" value="Логин" /><br/>

<span id="message"></span>

</form>

</div>

Здесь определена стандартная форма для отправки данных на сервер. Для обработки работы формы и формирования Ajax-запроса необходимо переопределить поведение формы с помощью JavaScript. Далее представлен фрагмент кода, определяющий логику работы формы:

<script type="text/javascript">

$('document').ready(function() {

$('#loginForm').submit(function(event) {

var postData = new Object();

postData.userName = $('#userName').val();

postData.password = $('#password').val();

postData.rememberMe = $('#RememberMe').is(':checked');

$.post('Account/LogOn',

postData,

function OnResult(result) {

if (result.IsSuccess) {

$('#loginPanel').hide();

$('#logoutPanel').show();

var username = $('#userName').val();

$('#username')

.html("<b>" + username + "</b>");

} else {

$('#message').text(result.ErrorString);

}

},

'json');

event.preventDefault();

})

});

</script>

Здесь определяется обработчик окончания загрузки документа, который после загрузки сайта в браузере у клиента выполнит необходимые привязки к разметке. Так, с помощью $('#loginForm').submit определяется функция, которая будет вызвана в момент, когда данные с формы будут передаваться на сервер. Обратите внимание на параметр event этой функции. После определения своей логики поведения при отправке данных с формы мы вызываем event.preventDefault(), который предотвращает поведение по умолчанию, т. е. позволяет нам отменить отправку данных с формы стандартным путем.

Для отправки данных мы используем функцию $.post, передав в нее предварительно сформированные данные, полученные с элементов управления. При вызове $.post мы определяем функцию OnResult, которая должна быть вызвана после завершения Ajax-запроса. Эта функция определяет обработку результата запроса и выводит либо сообщение об ошибке, либо приглашения для пользователя, в случае когда вход в систему был произведен удачно.

Полезные советы

В этой части главы мы рассмотрим несколько моментов, связанных с использванием технологии Ajax и библиотек jQuery и ASP.NET Ajax на практике.

Вопросы безопасности

Использование Ajax открывает новые возможности для разработчика и предлагает новый опыт для посетителя веб-ресурса. Но вместе с тем использование Ajax открывает новое поле действия для злоумышленников. Рассмотрим основные вопросы безопасности, которые следует иметь в виду при работе с запросами, в том числе и Ajax-запросами.

Обработка пользовательских данных

При работе с данными, полученными от пользователей, всегда необходимо соблюдать правила безопасности. Нужно относиться к любым таким данным как к потенциально опасным для отображения в разметке. Представим себе ситуацию, когда злоумышленник вместо того, чтобы ввести в поле своего логина какой-то текст, вводит туда опасный JavaScript-код. Тогда, если не принять никаких мер предосторожности, каждый из пользователей, который будет открывать страницу с выведенными данными злоумышленника на нашем сайте, потенциально будет уязвим. Предотвращение таких атак достигается путем декодирования опасного содержимого перед отображением на клиенте. В ASP.NET MVC существует метод расширения Html.Encode, который позволяет представить любой набор текстовых данных как безопасную последовательность символов и их HTML-представлений. Рассмотрим пример:

<div>

<%= Html.Encode("<script>alert('Атака удалась')</script>") %>

</div>

Очевидно, что если вывести строку, содержащую тег <script>, то она будет интерпретироваться браузером как JavaScript-код и ее содержимое выполнится. Но используя Html.Encode, мы получаем возможность избежать атаки. Результатом работы этой функции станет следующий текст разметки:

<div>

&lt;script&gt;alert('Атака удалась')&lt;/script&gt;

</div>

Как можно убедиться, метод расширения Html.Encode декодировал опасную строку в такую последовательность, которая выводится браузером как обычная строка текста, безопасная для клиентов.

При работе с Ajax иногда возникает необходимость возвращать данные в виде HTML-разметки, содержащей пользовательские данные. Это может привести к нарушению безопасности и атаке описанной ранее. Для предварительной обработки данных в действиях контроллера можно использовать методы статического класса Httputility. Httputility содержит массу методов для большинства сценариев обработки потенциально опасных данных: HtmlEncode, HtmlAttributeEncode, UrlEncode, UrllPathEncode.

Для более надежной защиты и предоставления дополнительного функционала Microsoft предлагает разработчикам бесплатную библиотеку AntiXSS, которая на момент написания книги имела версию 3.1 (библиотека доступна по адресу http://www.codeplex.com/AntiXSS). Данная библиотека обеспечивает еще более надежное декодирование потенциально опасных данных для обеспечения повышенных требований к безопасности. Кроме того, AntiXSS содержит полезные методы для разнообразных сценариев работы с данными и HTTP-модуль, который позволяет комплексно решать вопросы безопасности для проекта.

Управление данными и cookie

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

Однако следует знать, что использование cookie может привести к уязвимости сайта и к раскрытию пользовательских данных. Представим ситуацию: некоторый сайт производит обновление данных на базе строки запроса, полагаясь на произведенную авторизацию пользователя. И разумеется, данный сайт содержит современный механизм авторизации на базе cookie. Может сложиться впечатление, что это абсолютно безопасно, т. к. cookie хранится на компьютере пользователя, а обновление данных невозможно без подтвержденной авторизации. Однако здесь кроется ошибка, которая может привести к серьезному нарушению безопасности. Не будем предполагать, что cookie попросту может быть украден с компьютера пользователя, допустим, что вы предусмотрели такой вариант и кроме cookie проверяете еще и IP-адрес пользователя. Существует более простой вариант атаки и без доступа к cookie. Этот способ предполагает формирование на странице атакуемого сайта изображения с помощью доступного пользователям функционала. Только вместо адреса изображения злоумышленник может подставить строку запроса на модификацию данных. В таком случае все пользователи, зайдя на ресурс, при попытке просмотра картинки выполнят опасную строку запроса от своего имени. И в случае, если через строку запроса можно управлять данными, такой запрос может привести к печальным последствиям.

Мораль такова, что необходимо избегать управления пользовательскими данными через GET-запросы, которые формируются в том числе и строкой запроса. Все запросы, которые так или иначе приводят к модификации, созданию или удалению данных, необходимо оформлять через POST. Однако часто это очень неудобно для разработчика или вовсе невозможно. В таких случаях полезным будет следующее решение:

□ для каждой пользовательской сессии формируется некая строка с уникальным значением;

□ для всех запросов, которые модифицируют данные пользователя, добавляется некий параметр, содержащий сформированное уникальное значение, например, так: http://mysite/LogOut?hash=328947236401603167, где параметр hash содержит секретное значение, полученное на сервере;

□ в функционале, который занимается модификацией данных, производится проверка на переданное значение параметра, в случае если оно отсутствует или не соответствует созданному, предполагается нарушение безопасности;

□ злоумышленник не сможет сформировать строку параметра безопасности, т. к. не знает ее, и описанная ранее атака не сможет быть произведена путем подмены строки запроса.

Однако POST-запросы тоже могут быть подвергнуты атаке. Так, злоумышленнику достаточно сформировать страницу в Интернете, где он создаст форму с автоматической отправкой данных на атакуемый сайт. Ничего не подозревающий пользователь, открыв такую страницу, скрытно для себя авторизуется на своем сайте, предоставляя злоумышленнику выполнять от его имени любые операции. Этот тип атаки получил название Cross-Site Request Forgery (CSRF).

Защита от CSRF может быть осуществлена несколькими путями:

□ проверка поля Referer POST-запроса может показать истинный сайт, с которого производился запрос, на основании этой проверки можно защититься от атаки;

□ для каждой формы можно сформировать скрытое поле со сформированными секретными данными так, как мы делали это для GET-запросов. При отправке данных с формы скрытое поле также будет отправлено. Нам достаточно просто проверить соответствие переданных данных со сформированными на сервере, чтобы убедиться в том, что POST-запрос безопасен.

ASP.NET MVC содержит вспомогательный набор инструментов для реализации второго сценария защиты от CSRF-атак. Инструменты представляют собой метод расширения Html.AntiForgeryToken, который формирует скрытое поле в разметке:

<% using (Html.BeginForm()) { %>

... // здесь набор элементов управления

<%= Html.AntiForgeryTokenO %>

<input type="submit" value="Change Password" />

<% } %>

На примере показано использование метода расширения Html.AntiForgeryToken, который в результате сформирует следующую разметку:

<input name="_RequestVerificationToken" type="hidden"

value="71QjBJILoVngYTD+UZ3JTn8KMsJ/Yo48Q2sSOLo6cgpYHc2qOG4UudRujINZtg4L" />

Для проверки этого скрытого поля на сервере необходимо добавить к вызываемым действиям атрибут ValidateAntiForgeryToken так, как показано во фрагменте кода:

[ValidateAntiForgeryToken()]

public ActionResult ChangePassword(string currentPassword,

string newPassword, string confirmPassword)

Теперь любой POST-запрос к действию ChangePassword приведет к сопоставлению скрытого параметра формы с внутренним, сформированным на сервере. В случае, если параметры не совпадают, возникнет исключение, которое предотвратит несанкционированный доступ (рис. 7.11). Таким образом, проделав несложные действия, вы надежно защитите себя от CSRF-атак.

Расширения jQuery

Библиотека jQuery получила свое широкое распространение и огромную популярность не только за свои возможности в работе с DOM-моделью документа и Ajax. В большой степени популярности jQuery способствовало сообщество разработчиков, которые создавали и создают расширения к jQuery. Простота процесса создания плагинов к этой библиотеке послужила бурному росту числа расширений функционала jQuery. На текущий момент уже существует несколько тысяч всевозможных плагинов, которые помогают решать полный спектр задач на стороне клиента: от упрощения работы с данными до реализации богатых визуальных эффектов.

Существуют плагины jQuery и для упрощения работы с Ajax. Найти их можно по адресу http://plugins.jquery.com/project/Plugins/category/47, где на момент написания книги таких плагинов было представлено 182 штуки. В табл. 7.3 перечислены некоторые из них.

Выбор между ASP.NET Ajax и jQuery

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

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

□ Сложность. Предполагается, что для работы с jQuery требуются навыки JavaScript-разработки и знание принципов работы самой библиотеки. С другой стороны, ASP.NET Ajax предлагает решение задач, связанных с Ajax-запросами декларативным путем, знакомым каждому разработчику ASP.NET.

□ Перспективы. Используя jQuery, разработчик получает не только механизм управления Ajax-запросами, но и богатый функционал по работе с DOM-моделью. С помощью jQuery разработчик может производить очень быстрые и оптимизированные процедуры поиска, модификации, удаления и добавления элементов DOM. jQuery позволяет оперировать запросами с помощью мощных селекторов, основанных на синтаксисе селекторов CSS3. Это дает в руки разработчика мощный инструмент по быстрейшему доступу к любому набору элементов DOM-страницы на стороне клиента. С другой стороны, ASP.NET Ajax продолжает развиваться, и в версии 4.0 разработчиков ждет масса нововведений, которые позволят работать с данными на базе шаблонов, введут связывание данных и даже контексты данных. Эти высокоуровневые абстракции в перспективе могут значительно облегчить жизнь разработчика.

□ Затратность. Использование любой JavaScript-библиотеки означает дополнительные расходы на количество пересылаемой информации от сервера клиенту. С применением GZip-сжатия на стороне сервера размер передаваемых данных при использовании библиотеки jQuery составляет около двадцати килобайт. С применением функционала ASP.NET Ajax это число может увеличиться до двух раз. Но при расчете затратности необходимо учитывать потенциальное увеличение размера JavaScript-файлов при использовании сторонних или собственных плагинов к jQuery. Кроме того, в перспективе ASP.NET Ajax получит механизм гибкого контроля над размером JavaScript-кода, когда разработчик сможет указать, какие части функционала следует использовать и отсылать клиенту, что значительно уменьшит размер пересылаемых данных.

В идеале, проект на базе ASP.NET MVC может получить приемущества обеих библиотек, если использовать их вместе. Но на практике требования к проекту могут содержать такие условия, когда разработчику приходится выбирать. В таком случае выбор приходится делать на основании рассмотренных ранее условий. Однако если ваш проект не содержит ограничений, и вы можете позволить себе использование нескольких JavaScript-файлов, то авторы книги рекомендуют вам применять обе библиотеки для получения выгоды от разного функционала, которые они предлагают.

Заключение

В этой главе мы рассмотрели технологию Ajax, историю ее возникновения и значение этой технологии при построении веб-приложений в наше время. Мы подробно рассмотрели пару механизмов, которые содержатся в MVC Framework и которые позволяют работать с Ajax — это ASP.NET Ajax и jQuery. Нами были описаны функции, методы и структуры, с помощью которых работают эти механизмы. В завершение главы мы рассмотрели несколько примеров использования ASP.NET Ajax и jQuery для решения задач и привели советы по применению Ajax на практике.

Технология Ajax — это современная технология, которая все более широко распространяется в Интернете. Возникает все больше крупных и мелких вебпроектов, которые используют Ajax в той или иной мере. Многие старые проекты при обновлении также начинают использовать Ajax. В связи с этим понимание и умение использовать технологию на практике — это важное условие построения современного веб-сайта в наше время. И как мы показали в этой главе, MVC Framework предоставляет все возможности для работы с Ajax и поддерживает разработчика удобными инструментами.

ГЛАВА 8

Тестирование веб-приложений

В главах 1 и 2 книги было особо отмечено, что простота автоматизированного тестирования является одним из значительных преимуществ MVC Framework над WebForms. Пришло время рассмотреть более детально процесс автоматического тестирования веб-приложений, созданных на базе MVC Framwork.

В этой главе мы воспользуемся популярным решением с открытым кодом для создания автоматических тестов — NUnit, которое стало стандартом "де-факто" для многих команд веб-разработчиков на платформе Microsoft .NET.

Установка и настройка NUnit

Для начала необходимо загрузить и установить оснастку тестирования NUnit (http://www.nunit.org/?p=download). Затем установить шаблоны проектов тестирования (http://tinyurl.com/nunit-template), для этого нужно загрузить архив NUnit Test Templates, скопировать содержимое директории CSharp в директорию \Documents\Visual Studio 2008\Templates\ProjectTemplates\Visual C# (аналогично для директории Visual Basic, если вы используете язык Visual Basic), после чего загрузить данные из REG-файла в реестр для регистрации шаблона NUnit в мастере создания проектов ASP.NET MVC Framework.

Когда вы завершите процедуры установки NUnit и шаблонов проектов, при создании нового проекта ASP.NET MVC Framework появится возможность создать проект для тестирования с использованием NUnit (рис. 8.1).

После создания проекта вместе с проектом веб-приложения будет создан проект библиотеки классов, являющийся основной сборкой для тестирования веб-приложения, представленный на рис. 8.2.

Рис. 8.2. Проект тестирования веб-приложения

В случае если необходимо создать проект тестирования для уже существующего проекта, достаточно добавить в решение проект библиотеки классов, добавить в него ссылку на тестируемый проект и ссылку на сборку nunit.framework.dll, находящуюся в директории bin в директории установки NUnit, и создать тесты так, как будет показано далее в этой главе.

Создание и выполнение тестов

Набор простейших тестов, проверяющий корректность работы контроллера Home из шаблона веб-приложения, приведен в листинге 8.1.

Листинг 8.1. Тесты контроллера Ноше

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Web.Mvc;

using NUnit.Framework;

using MvcTestApp;

using MvcTestApp.Controllers;

namespace MvcTestApp.Tests.Tests.Controllers

{

[TestFixture]

public class HomeControllerTest

{

[Test]

public void Index()

{

HomeController controller = new HomeController();

ViewResult result = controller.Index() as ViewResult;

ViewDataDictionary viewData = result.ViewData;

Assert.AreEqual("Welcome to ASP.NET MVC!",

viewData["Message"]);

}

[Test]

public void About()

{

HomeController controller = new HomeController();

ViewResult result = controller.About() as ViewResult; Assert.IsNotNull(result);

}

}

}

Тесты представляют собой методы, помеченные атрибутом Test, помещенные в классы, помеченные атрибутом TestFixture. Среда выполнения тестов NUnit находит в сборке с тестами тестирующие методы именно по этим атрибутам.

Структура каждого теста может быть разбита на три основных элемента:

□ подготовка данных и объектов для проведения теста;

□ выполнение действия, результат которого нужно протестировать;

□ проверка результатов выполнения действия.

Рассмотрим тестовый метод Index из листинга 8.1, проверяющий одноименное действие контроллера Home.

Подготовка данных и объектов в этом случае представляет собой только лишь создание экземпляра класса HomeController.

HomeController controller = new HomeController();

Выполнение действия — вызов метода Index у созданного ранее объекта controller, возвращающего результат типа viewResult.

ViewResult result = controller.Index() as ViewResult;

Проверка результата в данном случае заключается в проверке значения, помещенного в коллекцию ViewData с ключом Message с помощью метода класса Assert, используемого для целей отладки и тестирования.

Assert.AreEqual("Welcome to ASP.NET MVC!", viewData["Message"]);

После того как тесты созданы, сборку, содержащую тесты, нужно скомпилировать и загрузить в графическую оболочку NUnit. Оболочка распознает методы, помеченные атрибутами Test, и выводит их в виде дерева тестов, как это показано на рис. 8.3.

Тесты можно выполнять по одному, либо блоками, относящимися к одному классу, содержащему тестирующие методы, либо все тесты сразу (рис. 8.4).

Теперь представим себе, что вследствие развития проекта результат выполнения метода Index изменился, и в коллекцию ViewData с ключом Message помещается другая строка.

public ActionResult Index()

{

ViewData["Message"] = "Всем привет!";

return View();

}

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

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

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

Несколько слов о важности тестирования

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

Примечание

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

*****************************

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

Тесты и MVC Framework

После прочтения предыдущей части главы можно было убедиться, что создание теста логики веб-приложения, построенного на базе MVC Framework, — задача простая. Этот эффект достигается за счет того, что ядро веб-приложения, состоящее из контроллеров и слоя работы с данными (моделей), может быть выделено в независимую от среды сборку и тестироваться вне контекста веб-сервера и без генерации разметки представления. Даже в тех случаях, когда среде выполнения необходимо взаимодействие с объектами, отвечающими за ввод/вывод разметки и запросов, передаваемых между пользователем и сервером, используются абстрактные классы (например, HttpRequestBase), реализация которых может быть подменена в тестовой среде.

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

Для поддержки возможности замены конкретной реализации необходимо использовать интерфейсы для основных зависимостей действий контроллеров. Например, если в приложении есть выделенный объект, отвечающий за восстановление и сохранение объектов данных DataManager, то в контроллерах следует использовать интерфейс iDataManager, который реализует конкретный класс DataManager. Таким образом, во время проведения тестов объект DataManager может быть подменен объектом DataManagerMock, не содержащим полного функционала работы с данными и, возможно, даже не работающим с базой данных. Этот распространенный подход к тестированию называется имитацией (англ. moking).

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

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

Листинг 8.2. Фрагмент кода класса Accountcontroller

public class Accountcontroller : Controller

{

public Accountcontroller() : this(null, null)

{

}

public AccountController(IFormsAuthentication formsAuth,

IMembershipService service)

{

FormsAuth = formsAuth ?? new FormsAuthenticationService();

MembershipService = service ?? new AccountMembershipService();

}

public IFormsAuthentication FormsAuth

{

get;

private set;

}

public IMembershipService MembershipService

{

get;

private set;

}

}

Поскольку в контроллере Accountcontroller используются компоненты инфраструктуры ASP.NET, отвечающие за аутентификацию пользователей и управление учетными записями, для них созданы специальные обертки, приведенные в листинге 8.3, реализующие интерфейсы IFormsAuthentication и IMembershipService.

Листинг 8.3. Интерфейсы и реализация поддержки базовых служб

public interface IFormsAuthentication

{

void SignIn(string userName, bool createPersistentcookie);

void SignOut();

}

public class FormsAuthenticationService : IFormsAuthentication

{

public void SignIn(string userName, bool createPersistentCookie)

{

FormsAuthentication.SetAuthCookie(userName,

createPersistentCookie);

}

public void SignOut()

{

FormsAuthentication.SignOut();

}

}

public interface IMembershipService

{

int MinPasswordLength { get; }

bool ValidateUser(string userName, string password);

MembershipCreateStatus CreateUser(string userName,

string password, string email);

bool ChangePassword(string userName,

string oldPassword, string newPassword);

}

public class AccountMembershipService : IMembershipService

{

private MembershipProvider _provider;

public AccountMembershipService()

: this(null)

{

}

public AccountMembershipService(MembershipProvider provider)

{

_provider = provider ?? Membership.Provider;

}

public int MinPasswordLength

{

get

{

return _provider.MinRequiredPasswordLength;

}

}

public bool ValidateUser(string userName, string password)

{

return _provider.ValidateUser(userName, password);

}

public MembershipCreateStatus CreateUser(string userName,

string password, string email)

{

MembershipCreateStatus status;

_provider.CreateUser(userName, password,

email, null, null, true, null, out status);

return status;

}

public bool ChangePassword(string userName,

string oldPassword, string newPassword)

{

MembershipUser currentUser = _provider.GetUser(

userName, true);

return currentUser.ChangePassword(oldPassword, newPassword);

}

}

Выделение обертки над службами ASP.NET позволяет не только получить возможность простого тестирования, но и заменять реализацию в процессе развития приложения. Например, при замене стандартного провайдера Membership на собственную реализацию или изменение провайдера авторизации для поддержки сертификатов, или Windows-аутентификация. Однако в целях тестирования этот подход просто незаменим.

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

Листинг 8.4. Классы для имитации в условиях тестирования

public class MockFormsAuthenticationService :

IFormsAuthentication

{

public void SignIn(string userName,

bool createPersistentcookie) { }

public void SignOut() { }

}

public class MockHttpContext : HttpContextBase

{

private IPrincipal _user;

public override IPrincipal User

{

get

{

if (_user == null)

{

_user = new MockPrincipal();

}

return _user;

}

set

{

_user = value;

}

}

}

Аналогично коду, приведенному в листинге 8.4, строятся остальные классы, используемые для тестирования. Основной принцип их создания состоит в том, чтобы развязать процесс тестирования с реальным функционалом — вместо работы с базами данных не делать ничего, либо возвращать стандартные значения, используемые для тестирования, и т. п.

Пример использования имитирующих классов в целях тестирования приведен в листинге 8.5. Процесс подготовки объектов выделен в отдельный метод GetAccountController() .

Листинг 8.5. Несколько методов для тестирования AccountController

private static AccountController GetAccountController()

{

IFormsAuthentication formsAuth = new

MockFormsAuthenticationService();

MembershipProvider membershipProvider = new MockMembershipProvider();

AccountMembershipService membershipService = new

AccountMembershipService(membershipProvider);

AccountController controller = new

AccountController(formsAuth, membershipService);

ControllerContext controllerContext = new

ControllerContext(new MockHttpContext(),

new RouteData(),

controller);

controller.ControllerContext = controllerContext;

return controller;

}

[Test]

public void RegisterPostReturnsViewIfPasswordIsNull()

{

AccountController controller = GetAccountController();

ViewResult result = (ViewResult)controller.Register("username",

"email", null, null);

Assert.AreEqual(6, result.ViewData["PasswordLength"]);

Assert.AreEqual(

"You must specify a password of 6 or more characters.",

result.ViewData.ModelState["password"].Errors[0].ErrorMessage);

}

[Test]

public void

RegisterPostReturnsViewIfNewPasswordDoesNotMatchConfirmPassword()

{

AccountController controller = GetAccountController();

ViewResult result = (ViewResult)controller.Register("username",

"email", "password", "password2");

Assert.AreEqual (6, result.ViewData["PassworcLLength"] );

Assert.AreEqual(

"The new password and confirmation password do not match.",

result.ViewData.ModelState["_FORM"].Errors[0].ErrorMessage);

}

[Test]

public void RegisterPostReturnsViewIfPasswordIsTooShort()

{

AccountController controller = GetAccountController();

ViewResult result = (ViewResult)controller.Register("username",

"email", "12345", "12345");

Assert.AreEqual(6, result.ViewData["PasswordLength"]);

Assert.AreEqual(

"You must specify a password of 6 or more characters.",

result.ViewData.ModelState["password"].Errors[0].ErrorMessage);

}

[Test]

public void RegisterPostReturnsViewIfRegistrationFails()

{

AccountController controller = GetAccountController();

ViewResult result = (ViewResult)controller.Register("someUser",

"DuplicateUserName" /* error */, "badPass", "badPass");

Assert.AreEqual(6, result.ViewData["PasswordLength"]);

Assert.AreEqual(

"Username already exists. Please enter a different user name.",

result.ViewData.ModelState["_FORM"].Errors[0].ErrorMessage);

}

[Test]

public void RegisterPostReturnsViewIfUsernameNotSpecified()

{

AccountController controller = GetAccountController();

ViewResult result = (ViewResult)controller.Register("", "email",

"password", "password");

Assert.AreEqual(6, result.ViewData["PasswordLength"]);

Assert.AreEqual("You must specify a username.",

result.ViewData.ModelState["username"].Errors[0].ErrorMessage);

}

Основная концепция, продемонстрированная в листинге 8.5, заключается в использовании "подставных" реализаций везде, где применяются реализации, не зависящие от кода, описанного в самом контроллере, а также в создании отдельных тестовых методов для разных сценариев выполнения одного и того же действия контроллера.

Заключение

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

ГЛАВА 9

ASP.NET MVC 2 и Visual Studio 2010

Пока писалась эта книга, процесс разработки ASP.NET MVC Framework не стоял на месте. Сначала вышла предварительная версия ASP.NET MVC Preview 1, а затем и ASP.NET MVC Preview 2. Некоторое время спустя была выпущена и новая версия инструмента разработчиков Visual Studio 2010 Beta 2. На момент написания этой части книги Visual Studio 2010 Beta 2 и ASP.NET MVC Preview 2 — последние версии, доступные широкой аудитории разработчиков.

Новая вторая версия ASP.NET MVC принесла во Framework значительную порцию нового функционала, новых концепций, новых удобных инструментов и API. В этой части книги мы бы хотели кратко осветить то, что предлагается разработчиками ASP.NET в предварительных версиях Framework.

Области

Понятие областей (areas) для ASP.NET MVC — новая концепция. Суть областей сводится к тому, чтобы предоставить возможность разделить чрезмерно большой проект на несколько групп, которые продолжали бы взаимодействовать друг с другом. Например, в компании работает несколько групп разработчиков, которые создают большой проект, включающий в себя: основной сайт, магазин, обзоры товаров, форум, внутренний сайт по администрированию и пр. Для создания такого проекта ASP.NET MVC 2 предлагает выделить каждую отдельную часть проекта в область, вместе эти области продолжали бы представлять собой один взаимосвязанный проект. Выделение из большого проекта отдельных проектов-областей позволит разным группам разработчиков более независимо разрабатывать свои части приложения.

Предположим, что в крупной компании разрабатывается большой проект на базе ASP.NET MVC. Обычно группы, работающие над разными частями проекта, независимы друг от друга и связаны только спецификацией. Поэтому очень важно не допустить возможных конфликтов в программном коде, которые могут возникнуть, когда несколько частей большого проекта сливаются в одно целое. Так, например, группы, разрабатывающие части, отвечающие за магазин и за блог сайта, могут независимо друг от друга создать одноименные контроллеры AdminController. В случае, когда проект не основан на областях, слияние двух независимых частей с одноименным контроллером может быть сильно затруднено или невозможно. С использованием областей данная проблема решается, т. к. каждая область может иметь свой собственный независимый набор контроллеров.

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

Концепция областей появилась в ASP.NET MVC 2 Preview 1 в виде областей в решении с несколькими проектами. После выхода ASP.NET MVC 2 Preview 2 применение областей было расширено возможностью создавать области в одном проекте. Рассмотрим оба варианта.

Области для нескольких проектов

При создании решения с использованием областей, работающих для нескольких проектов, необходимо следовать следующим шагам:

1. Создать проект, который будет родительским (или главным) по отношению к проектам-областям.

2. Создать проекты-области, например, для форума, блога, магазина и т. д. В этих проектах требуется удалить файлы Global.asax, кроме того, можно удалить созданные по умолчанию файлы в папку Scripts, поскольку все скрипты будут браться из родительского проекта.

3. Добавить ссылки на проекты-области в родительском проекте.

4. Создать для каждого из проектов класс, наследующий от класса AreaRegistration, в котором перегрузить два элемента: метод RegisterArea и свойство AreaName. RegisterArea должен реализовать логику по регистрированию области в контексте приложения, свойство AreaName должно вернуть название области.

5. В родительском проекте в Global.asax необходимо вызвать метод AreaRegistration.RegisterAllAreas(); для регистрации областей в контексте приложения во время запуска.

6. Заключительным шагом, который требуется для успешного запуска проекта с областями, является модификация файлов проекта *.csproj (*.vbproj для проектов на Visual Basic) каждого из проектов. В каждого таком файле необходимо раскомментировать относящиеся к областям строки кода (будет показано далее).

Рассмотрим шаги немного подробнее. На рис. 9.1 показана структура решения, в котором содержится три проекта: родительский проект AreasProject и два проекта-области — Forum и Store, которые реализуют логику форума и магазина соответственно.

Рис. 9.1. Структура проекта ASP.NET MVC с областями

В проекте-области Forum создан контроллер ForumController, который реализует три действия: Index, AddPost, EditPost. Точно так же в проекте Store создан контроллер ProductsController с действиями List, AddReview и Details. Для отображения результатов действий созданы соответствующие представления. После создания проектов-областей в проект AreasProject были добавлены ссылки на эти проекты.

На рис. 9.1 вы можете заметить в проектах Store и Forum файл Routes.cs. Этот файл добавлен в проекты для того, чтобы реализовать класс AreaRegistration. Рассмотрим содержимое файла Routes.cs в проекте Store в листинге 9.1.

Листинг 9.1. Содержимое файла Routes.cs проекта Store

namespace Store

{

using System.Web.Mvc;

using System.Web.Routing;

public class Routes : AreaRegistration

{

public override void RegisterArea(

AreaRegistrationContext context)

{

context.MapRoute(

"Store_Default",

"Store/{controller}/{action}/{id}",

new {controller = "Products",

action = "List", id = ""},

new string[] { "Store.Controllers" }

);

}

public override string AreaName

{

get { return "Store"; }

}

}

}

Обратите внимание, класс Routes наследуется от AreaRegistration, что позволит подсистеме ASP.NET MVC в дальнейшем проинициализировать с помощью него подсистему областей. В классе Routes содержится два перегруженных члена: метод RegisterArea и свойство AreaName.

В RegisterArea производится регистрация маршрутов в контексте приложения с областями. С помощью context.MapRoute создается маршрут под названием store_Default. Последнее значение параметра new string[] { "Store.Controllers" } определяет пространство имен, в котором находятся контроллеры, сопоставленные данному маршруту.

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

Классы, подобные Routes для проекта Store, необходимо создать для каждого проекта в решении с областями.

Следующим шагом будет добавление в родительском проекте AreasProject в Global.asax следующей строки кода:

protected void Application_Start()

{

AreaReg±stration.Reg±sterAllAreas();

RegisterRoutes(RouteTable.Routes);

}

Вызов AreaRegistration.RegisterAllAreas() при запуске приложения позволит ASP.NET MVC инициализировать все имеющиеся области и их маршруты в приложении.

Последним шагом, необходимым для запуска проекта с областями, является модификация файлов проекта *.csproj (или *.vbproj, если ваши проекты написаны на Visual Basic) для каждого из проектов в решении. Для того чтобы получить доступ к этим файлам, последовательно выгрузите проекты из решения с помощью команды UnloadProject. В контекстном меню на выгруженном проекте выберите Edit***.csproj (рис. 9.2), где *** — название проекта.

Рис. 9.2. Контекстное меню, позволяющее редактировать файл проекта

В файлах проектов содержится часть закомментированных определений, которые требуется раскомментировать для использования решения на базе областей. Для проектов-областей это куски кода с комментариями:

<!— To enable MVC area subproject support, uncomment the following two lines: —>

и

<!-- If this is an area child project, uncomment the following line: -->

Для родительского проекта необходимо раскомментировать куски кода, помеченные:

<!— To enable MVC area subproject support, uncomment the following two lines: -->

и

<!-- If this is an area parent project, uncomment the following lines: -->

Примечание

Возможно, что в следующих релизах ASP.NET MVC 2 действие с редактированием файлов проекта будет излишним. Ожидается, что работа с областями будет поддерживаться на уровне Solution Explorer, что облегчит создание новых областей и проектов на их базе.

*****************************

Теперь, когда проект подготовлен полностью, можно использовать проекты-области в родительском проекте следующим образом. Видоизменим в файл Site.Master в родительском проекте блок кода списка вкладок так, чтобы он выглядел, как во фрагменте:

<ul id="menu">

<li><%= Html.ActionLink("Home", "Index", "Home",

new {area = "AreasProject"}, null)%></li>

<li><%= Html.ActionLink("Forum", "Index", "Forum",

new { area = "Forum" }, null) %></li>

<li><%= Html.ActionLink("Store", "List", "Products",

new { area = "Store" }, null) %></li>

<li><%= Html.ActionLink("About", "About", "Home",

new {area = "AreasProject"}, null)%></li>

</ul>

Обратите внимание, что построение ссылок с помощью Html.ActionLink теперь требует указания области, в которой нужно найти контроллер и действие. Если мы запустим проект, то увидим следующее (рис. 9.3).

Новые вкладки Store и Forum будут работать согласно заданным правилам и отображать представления из проектов-областей.

Области в одном проекте

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

В родительском проекте AreasProject в папке Views/Areas создаются скрытые элементы из проектов-областей. Это требуется для того, чтобы родительский проект самостоятельно отображал представления проектов-областей.

Однако эта структура скрытых файлов может быть использована и напрямую. В ASP.NET MVC 2 Preview 2 появилась возможность создания решений с одиночными проектами на базе областей. Такие решения содержат только один проект, в котором реализованы все области. На рис. 9.5 представлена структура одиночного проекта, где реализованы те же самые области, которые были реализованы в предыдущем разделе с помощью нескольких проектов-областей.

Чтобы создать такой проект, по аналогии с предыдущим примером, мы должны создать вместо нескольких проектов иерархию областей в одном проекте. Для этого в корне проекта необходимо создать папку Areas, в которой каждая созданная папка будет являться отдельной областью. На рис. 9.5 такими папками являются Forum и Store. В них следует создать папку Controllers и Views для контроллеров и представлений и реализовать их подобно тому, как мы сделали это в предыдущем разделе. Обратите внимание, что для каждой папки-области также нужно создать файл Routes.cs с реализацией класса AreaRegistration. Необходимо обновить и Global.asax, добавив в него вызов AreaRegistration.RegisterAllAreas ().

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

Функционал областей — это полезный механизм, который позволяет разделить в большом решении логику различных частей на составные объекты — области. Вы можете выбрать, как области будут представлены в вашем решении: на базе нескольких проектов или же на базе только одного проекта. В любом случае, создание областей не составит труда и позволит вам удобно разделить разнородные функции в приложении.

Шаблонные помощники

Шаблонные помощники (templated helpers) — это новое средство в MVC 2, которое призвано сократить время разработки представлений. Шаблонные помощники строго типизированы и основаны на моделях приложения, кроме того, для вывода информации и валидации модели используется механизм DataAnnotations. В общем, шаблонных помощников можно представить себе как генератор разметки на базе определенной модели и правил, указанных с помощью атрибутов DataAnnotations.

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

Для примера рассмотрим следующую модель данных:

public class Product

{

public int Id { get; set; }

public string Name { get; set; }

public string Description { get; set; }

public decimal Cost { get; set; }

public DateTime UpdatedAt { get; set; }

}

Класс Product представляет собой модель продукта для некого магазина. Модель содержит идентификатор, название, описание, стоимость и дату обновления.

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

Листинг 9.2. Представление с использованием шаблонных помощников

<%@ Page Title="" Language="C#"

MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<TemplatedHelpersProject.Models.Product> " %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Информация о продукте

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<h2>Info</h2>

<%= Html.DisplayFor(x => Model)%>

</asp:Content>

Обратите внимание на выделенный участок кода, который представляет собой одну строчку шаблонного помощника, предназначенную для вывода информации о переданном экземпляре модели.

Код контроллера StoreController для примера будет таким, как в листинге 9.3.

Листинг 9.3. Контроллер StoreController

namespace TemplatedHelpersProject.Controllers

{

using System;

using System.Web.Mvc;

using TemplatedHelpersProj ect.Models;

public class StoreController : Controller

{

public ActionResult Info()

{

var product = new Product() { Cost = 1,

Description = "Описание",

Id = 1, Name = "Товар",

UpdatedAt = DateTime.Now };

return View(product);

}

}

}

Запустим приложение на выполнение и перейдем на представление Store/Info. Результатом будет полная информация, заведенная нами в экземпляре Product (рис. 9.6).

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

Шаблоны по умолчанию

Для работы с шаблонами по умолчанию ASP.NET MVC предлагает несколько стандартных методов расширения:

□ Html.LabelFor — производит рендеринг описательной информации для данных модели. По умолчанию выводит название поля модели;

□ Html.DisplayFor — производит рендеринг значений данных модели в соответствии с их типом;

□ Html.EditorFor — производит рендеринг элементов управления с данными модели для возможности редактирования.

Примечание

Кроме перечисленных стандартных методов расширения, в будущем планируется добавить методы: ValidationMessageFor, TextAreaFor, TextBoxFor, HiddenFor, DropDownListFor для соответствующей поддержки валидации и элементов управления в различных представлениях.

************************

Для всех этих методов расширения есть дополнительные методы LabelForModel, DisplayForModel и EditorForModel, которые являются сокращенным вариантом своих аналогов. Эти методы предназначены для рендеринга всей модели данных целиком без указания параметров.

Рассмотрим вариант рендеринга модели с помощью стандартных методов расширения. Для этого сформируем следующее представление (листинг 9.4).

Листинг 9.4. Модифицированное представление

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<TemplatedHelpersProj ect.Models.Product> " %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Info

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<div>

<fieldset>

<legend>Информация</legend>

<dl>

<dt><%= Html.LabelFor(x => Model.Name) %></dt>

<dd><%= Html.DisplayFor(x => Model.Name) %></dd>

<dt><%= Html.LabelFor(x => Model.Cost) %></dt>

<dd><%= Html.DisplayFor(x => Model.Cost) %></dd>

<dt><%= Html.LabelFor(x => Model.Description) %></dt>

<dd><%= Html.DisplayFor(x => Model.Description) %></dd>

</dl>

</fieldset>

</div>

</asp:Content>

Результат работы данного кода представлен на рис. 9.7.

Обратите внимание, что с использованием методов Html.LabelFor и Html.EditorFor для каждого элемента модели мы получили возможность осуществлять рендеринг данных в таком виде, в котором нам бы этого хотелось. Вместо стандартной разметки с использованием <div>, которая производится при автоматическом рендеринге всей модели, мы использовали тег <dl> для представления только той ее части, которая нужна нам.

Создание шаблонов

Существует большая вероятность того, что один и тот же рендеринг одного и того же типа данных вам предстоит выполнить в разных представлениях. Для того чтобы поддержать такой сценарий, ASP.NET MVC предлагает разработчику создать один-единственный шаблон рендеринга типа данных, а затем использовать его во всех необходимых местах.

Для того чтобы создать шаблон представления типа данных, необходимо в папке нужного контроллера в папке представлений Views создать одну из папок: DisplayTemplates или EditorTemplates. DisplayTemplates должна содержать шаблоны для рендеринга представлений для просмотра, а EditorTemplates — для редактирования. Папки DisplayTemplates и EditorTemplates содержат частичные представления *.ascx, наименование которых соответствуют типам данных, с которыми необходимо работать.

Например, на рис. 9.8 в папке Views/Store представлена папка DisplayTemplates, которая содержит частичное представление Product.ascx. Это означает, что для рендеринга данных типа Product при работе в контроллере storeController будет использоваться шаблон Product.ascx.

Содержимое Product.ascx представлено в листинге 9.5.

Листинг 9.5. Содержимое Product.ascx

<%@ Control Language="C#"

Inherits="System.Web.Mvc.ViewUserControl<TemplatedHelpersProj ect.Models. Product>"

%>

<div>

<fieldset>

<legend>ИНформация</legend>

<dl>

<dt>

<%= Html.LabelFor(x => Model.Name) %>

</dt>

<dd>

<%= Html.DisplayFor(x => Model.Name) %>

</dd>

<dt>

<%= Html.LabelFor(x => Model.Cost) %>

</dt>

<dd>

<%= Html.DisplayFor(x => Model.Cost) %>

</dd>

<dt>

<%= Html.LabelFor(x => Model.Description) %>

</dt>

<dd>

<%= Html.DisplayFor(x => Model.Description) %>

</dd>

</dl>

</fieldset>

</div>

Как вы можете убедиться, шаблон Product.ascx соответствует той разметке, которую мы создавали для рендеринга в листинге 9.4. Однако если теперь модифицировать код листинга 9.4 до простого варианта <%= Html.DisplayFor (x => Model) %>, то результат останется неизменным, т. к. механизм ASP.NET MVC, обнаружив имеющийся шаблон Product.ascx, использует его для рендеринга представления модели с типом Product.

Аннотация данных и валидация

ASP.NET MVC 2 имеет поддержку валидации данных на основании аннотации с помощью атрибутов из пространства имен System.ComponentModel.DataAnnotations.

Давайте улучшим наше представление, внеся изменение в модель так, как показано в листинге 9.6.

Листинг 9.6. Модель данных с аннотациями

namespace TemplatedHelpersProj ect.Models

{

using System;

using System.ComponentModel;

using System.ComponentModel.DataAnnotations;

using System.Web.Mvc;

public class Product

{

[DisplayName("Идентификатор")]

[HiddenInput]

public int Id { get; set; }

[DisplayName("Наименование товара")]

[Required(ErrorMessage = "Не указано наименование")]

public string Name { get; set; }

[DisplayName("Описание")] public string Description { get; set; }

[DisplayName("Цена")]

[Required(ErrorMessage="He указана цена")]

public decimal Cost { get; set; }

[DisplayName("Дата обновления")]

[HiddenInput(DisplayValue=false)]

public DateTime UpdatedAt { get; set; }

}

}

Обратите внимание на используемые атрибуты из пространства имен System.ComponentModel.DataAnnotations. С помощью этих атрибутов модель данных помечается метаданными, которые в дальнейшем автоматически используются в разных частях программы. Для демонстрации этого использования рассмотрим новое представление Edit для контроллера StoreController, предназначенное для редактирования данных (листинг 9.7).

Листинг 9.7. Представление для редактирования данных модели типа Product

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

Inherits="System.Web.Mvc.ViewPage<TemplatedHelpersProj ect.Models.Product> "

%>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent"

runat="server">

Редактирование информации

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent"

runat="server">

<h2>Товар</h2>

<%= Html.ValidationSummary() %>

<% using(Html.BeginForm()) {%>

<%= Html.EditorFor(x => Model) %>

<input type="submit" value="Обновить" />

<%} %>

</asp:Content>

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

В контроллере storeController добавим действия Edit (листинг 9.8).

Листинг 9.8. Действия Edit

public ActionResult Edit()

{

var product = new Product() {

ost = 1,

Description = "Описание",

Id = 1,

Name = "Товар",

UpdatedAt = DateTime.Now };

return View(product);

}

[HttpPost]

public ActionResult Edit(Product product)

{

return View(product);

}

Теперь, запустив приложение на выполнение, перейдя на Store/Edit и пробуя обновить данные без указания некоторых полей, мы получим такую картину (рис. 9.9).

Обратите внимание на то, что подписи к полям и сообщения об ошибках валидации соответствуют тем данным, которые были заведены нами через атрибуты аннотации данных. Кроме того, с помощью атрибута Hiddeninput нам удалось скрыть данные о времени обновления и изменить представление поля идентификатора с редактируемого поля на обычное текстовое поле.

Этот пример показывает, как использование атрибутов DisplayName, Hiddeninput, Required и др. из пространства имен System.Component-Model.DataAnnotations позволяет создать для модели набор метаданных, которые позже используются ASP.NET MVC для формирования разметки, подписей к полям ввода и валидации и вывода информации об ошибках.

Кроме поддержки валидации на сервере, ASP.NET MVC 2 предлагает поддержку валидации и на клиенте с помощью библиотеки валидации, написанной для jQuery. Для автоматической валидации данных на стороне клиента по умолчанию поддерживаются следующие атрибуты аннотирования данных:

StringLengthAttribute, RequiredAttribute, RegexAttribute, RangeAttribute.

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

<script type="text/javascript" src="MicrosoftAj ax.js"></script>

<script type="text/javascript" src="MicrosoftMvcAj ax.js"></script>

и для формы указать на необходимость использования клиентской валидации

<% using(Html.BeginForm()) { %>

//...

<% Html.EnableClientValidation(); %>

<% } %>

Кроме того, финальный вариант ASP.NET MVC 2 будет поддерживать новый механизм адаптеров, который позволит вам написать свой собственный провайдер клиентской валидации.

Классы метаданных

Существуют сценарии, когда аннотирование классов не представляется возможным, например, когда класс является автогенерируемым классом контекста данных Linq To Sql. Кроме того, вероятны сценарии, когда получение данных аннотации необходимо производить не с помощью атрибутов System.ComponentModel.DataAnnotations, а из других источников: базы данных или файлов XML.

Для поддержки таких сценариев в ASP.NET MVC введен механизм классов метаданных. Класс метаданных представляет собой обычный класс, служащий только для одной цели — предоставлять дополнительные данные — метаданные — о другом классе. Для примера добавим к нашему классу Product класс с метаданными, вынеся все данные аннотации в метакласс (листинг 9.9).

Листинг 9.9. Класс с метаданными для класса Product

namespace TemplatedHelpersProject.Models {

using System;

using System.ComponentModel;

using System.ComponentModel.DataAnnotations;

using System.Web.Mvc;

[MetadataType (typeof (ProductMetadata)) ]

public class Product

{

public int Id { get; set; }

public string Name { get; set; }

public string Description { get; set; }

public decimal Cost { get; set; }

public DateTime UpdatedAt { get; set; }

}

public class ProductMetadata

{

[DisplayName("Идентификатор")]

[HiddenInput]

public int Id { get; set; }

[DisplayName("Наименование товара")]

[Required(ErrorMessage = "Не указано наименование")]

public string Name { get; set; }

[DisplayName("Описание")]

public string Description { get; set; }

[DisplayName("Цена")]

[Required(ErrorMessage="Не указана цена")]

public decimal Cost { get; set; }

[DisplayName("Дата обновления")]

[HiddenInput(DisplayValue=false)]

public DateTime UpdatedAt { get; set; }

}

}

Обратите внимание на выделенную строку [MetadataType(typeof (ProductMetadata))]. Атрибут MetadataType используется для того, чтобы показать механизму ASP.NET MVC, в каком классе следует искать метаданные. После выполнения кода мы убедимся, что перемещение метаданных из класса Product в класс ProductMetadata никак не отразилось на результате. Данные метаинформации стали потребляться из класса ProductMetadata, что и требовалось достичь.

Новые атрибуты

ASP.NET MVС 2 представляет набор новых атрибутов для разнообразных сфер применения. Далее вы найдете более полное описание.

Http***Attribute и перегрузка типов запросов

Ранее в ASP.NET MVC для ограничения выполнения действия в ответ на тип запроса применялся атрибут AcceptverbsAttribute с параметрами из перечисления HttpVerbs. В ASP.NET MVC 2 представлены альтернативные атрибуты для короткой записи: HttpPostAttribute, HttpPutAttribute, HttpGetAttribute, HttpDeleteAttribute.

Кроме атрибутов сокращенной формы, ASP.NET MVC 2 предлагает еще один механизм работы с запросами, который нацелен на REST-сценарии. При работе с REST-приложениями важной задачей ставится правильное оперирование типами запросов. Однако не все браузеры поддерживают типы запросов типа PUT или DELETE. Для преодоления этой проблемы в MVC 2 вводится новый метод расширения Html.HttpMethodOverride, который используется для перегрузки типа запроса, применяемого на форме. Например, в следующем коде формируется POST-форма (по умолчанию) с перегрузкой параметра запроса в PUT с помощью Html.HttpMethodOverride:

<% using(Html.BeginForm()) {%>

<%= Html.HttpMethodDverride(HttpVerbs.Put) %>

<%} %>

Этот механизм работает следующим образом: вызов Html.HttpMethodOverride формирует на форме следующее скрытое поле:

<input name="X-HTTP-Method-Override" type="hidden" value="PUT" />

При получении запроса с формы ASP.NET MVC ищет скрытое поле со значением X-HTTP-Method-Override и, если оно найдено, предполагает, что запрос представляет собой тип, указанный в скрытом поле. Таким образом, указанный ранее пример вызовет действие, помеченное атрибутом HttpPut, но не HttpPost, т. к. форма содержит перегруженный тип запроса. Перегрузка значения может выполняться не только с помощью скрытого поля, но и с помощью заголовков HTTP или параметров строки запроса.

Следует учесть, что перегрузка запросов возможна только для POST-запросов. Во всех других случаях скрытый параметр X-HTTP-Method-Override игнорируется.

DefauItValueAttribute

С помощью атрибута System.ComponentModel.DefaultValueAttribute в MVC 2 становится возможным указывать значения по умолчанию для параметров действий.

public class ArticleController

{

public ActionResult View(int id, [DefaultValue(1)]int page)

{

}

}

В приведенном ранее примере для параметра page определяется значение по умолчанию, которое следует использовать в случаях, когда запрос не содержал явного указания значения для данного параметра. Эта задача может быть решена для всех действий сразу через создание параметров маршрутизации по умолчанию. Но в случаях, когда требуется создать разные значения по умолчанию для разных действий, может быть использован атрибут DefaultValue.

RequireHttpsAttribute

Новый атрибут RequireHttpsAttribute в MVC 2 позволит вам пометить действия, вызов которых должен быть произведен только по защищенному протоколу HTTPS.

Улучшения в связывании данных

ASP.NET MVC 2 предоставит новую возможность по связыванию данных. Теперь в MVC 2 связывание данных возможно и с бинарными типами данных, представленными byte[] и System.Data.Linq.Binary. Для этих целей введены два новых перегруженных метода расширения Hidden:

public static string Hidden(this HtmlHelper htmlHelper, string name, Binary value);

public static string Hidden(this HtmlHelper htmlHelper, string name, byte[] value);

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

Прочие улучшения в API

Кроме перечисленных ранее значительных нововведений, ASP.NET MVC 2 предложит еще ряд менее значительных изменений в API:

□ новый защищенный виртуальный метод createActioninvoker в классе controller, который вызывается свойством Actioninvoker и позволяет создавать отложенное создание экземпляра (instantiation) инициатора, если он не установлен;

□ новый защищенный виртуальный метод OnAuthorizationFailed в классе AuthorizationFilter, который позволяет фильтрам авторизации отрабатывать ситуации, когда авторизация была провалена;

□ новый метод Add(stringkey, object value) у класса ValueProviderDictionary, который позволяет проще задавать значения для экземпляров класса;

□ новое свойство ActionDescriptor в классе AuthorizationContext;

□ метод Controller.Execute теперь вызовет исключение в ситуации, когда он вызван более одного раза в одном экземпляре. Это означает явное ограничение на вызов единственного экземпляра контроллера на каждый запрос;

□ класс Controller более не наследуется от MarshalByRefObject;

□ конструктор AuthorizationContext(ControllerContext context) объявлен устаревшим, вместо него предлагается использовать вариант с двумя параметрами;

□ внесены изменения в типы моделей так, что они теперь могут быть не только ссылочными типами, но и значениями. Например, в MVC 2 можно будет использовать System.Int32 как тип модели;

□ поиск контроллеров в пространстве имен, указанном при регистрации маршрутов, теперь будет выполняться и в подпространствах имен.

Кроме нововведений, MVC 2 содержит изменения, которые "ломают" совместимость с существующим кодом:

□ из класса DefaultControllerFactory исключено свойство RequestContext, вместо этого значение RequestContext передается в методы GetControllerinstance и GetControllerType. Это изменение нарушает работу пользовательских вариантов фабрики контроллеров, которые наследовались от класса DefaultControllerFactory;

□ строковое значение area в MVC 2 стало зарезервированным значением, которое нельзя использовать в качестве параметров маршрута при создании маршрутизации. В этом area стало похоже на бывшие ранее зарегистрированными строки controller и action;

□ методы расширения хелпер-классов (вспомогательных классов) отныне возвращают MvcHtmlString, вместо строки. Это нововведение рассчитано на использование в окружении ASP.NET 4.0 для получения преимуществ от нового синтаксиса элементов HTML-кодирования;

□ действия, которые возвращают JsonResult, в MVC 2 обязаны вызываться только в ответ на POST-запросы, это ограничение введено в целях повышения безопасности, поскольку обнаружены новые типы атак JSON Hijacking, осуществляемые при GET-запросах JSON-данных. Однако MVC 2 будет поддерживать способ обойти это ограничение через использование свойства JsonRequestBehavior у класса JsonResult;

□ свойства Model и ModelType объявлены устаревшими, вместо них предлагается использовать новое свойство ModelMetadata, которое содержит в себе данные Model и ModelType.

Нововведения Visual Studio 2010

Релиз Visual Studio 2010 будет содержать финальную версию ASP.NET MVC 2. Для более полной поддержки работы с MVC в Visual Studio 2008 и 2010 будут внесены некоторые изменения: введена поддержка создания областей с помощью элементов интерфейса и помощников, добавлены сниппеты (snippet — фрагмент) для быстрого создания кусочков кода.

Кроме того, MVC 2 будет содержать новый тип проекта, который будет представлять собой облегченный, "пустой" вариант текущего проекта MVC. В нем будут отсутствовать готовые контроллеры AccountController, HomeController и не будет готовых представлений или элементов страниц MasterPage.

Visual Studio 2010 получит новый профиль среды разработки под названием Web Development (Code Optimized). Профиль среды разработки определяет набор инструментов и внешний вид Visual Studio. Профиль Code Optimized оптимизирован для более удобного набора кода и увеличения рабочего пространства за счет сокрытия панелей с кнопками и элементами управления.

Далее приведены еще некоторые полезные нововведения в Visual Studio 2010, которые могут быть полезны при разработке проектов на ASP.NET MVC.

Мультитаргетинг в Visual Studio 2010

В Visual Studio 2010 понятие мультитаргетинга, т. е. поддержка сразу нескольких версий платформы .NET, приобретает новые возможности. Так как .NET 4.0 Framework содержит новую версию исполняемой среды CLR 4.0, то при установке Framework не заменит собой .NET 3.5, но предложит двум версиям существовать одновременно. Теперь, в зависимости от выбранной версии Framework (рис. 9.10), IntelliSense в Visual Studio будет отображать именно характерные для номера Framework имена методов, свойств, полей и т. д.

Поддержка нескольких мониторов

Для удобства разработчиков, которые используют в своей работе несколько мониторов (от двух и более), Visual Studio 2010 содержит ряд нововведений, которые помогут в полной мере задействовать мониторы в работе.

В связи с тем, что все окна в Visual Studio 2008 были частью одного главного окна, пользователи не имели возможности вынести часть окон на другие мониторы. В Visual Studio 2010 это проблема решена, теперь разработчик может расположить любые панели инструментов, информационные окна, окна редакторов кода и другие на разных мониторах (рис. 9.11).

Сниппеты JavaScript, Html, ASP.NET в Visual Studio 2010

Сниппет — это полезный инструмент, который позволяет сократить время, затрачиваемое разработчиком на набор кода. Сниппет представляет собой короткую команду, которая разворачивается в некий шаблон кода. Например, сниппет foreach для C# разворачивается в одноименный шаблон создания цикла foreach. Для того чтобы использовать сниппет, необходимо набрать его и нажать клавишу <Tab>. Есть и другой способ: можно вызвать список сниппетов с помощью комбинации клавиш <Ctrl>+<K>, <Ctrl>+<X> и выбрать необходимый сниппет из списка.

Visual Studio 2010 вводит поддержку сниппетов для быстрого набора HTML-, ASP.NET- и JavaScript-кода (рис. 9.12). Использование сниппетов позволит значительно ускорить рутинный набор кода для ASP.NET-страниц и элементов управления или скриптов JavaScript.

Что дальше?

Кроме перечисленных ранее функций, которые появились в MV C 2 Preview 2, планируется, что финальный вариант ASP.NET MVC 2 будет содержать еще ряд нововведений:

□ методы расширения Html.RenderAction и Html.Action, которые ранее являлись частью библиотеки MVC Futures, станут частью MVC 2. Эти методы предназначены для формирования разметки на основе результата действия и внедрении ее в определенное представление. Таким образом, в представлении можно будет выводить результат действий из других контроллеров;

□ будет расширен набор строготипизированных вспомогательных методов расширения для работы с шаблонами, добавятся методы: ValidationMessageFor, TextAreaFor, TextBoxFor, HiddenFor, DropDownListFor;

□ изменится поведение TempDataDictionary. Ее значения будут удаляться не после второго запроса, а сразу после чтения, что означает, что если данные TempData были прочтены в контексте этого же запроса, то они не будут доступны в следующем, как это могло бы быть в первой версии MVC. Данные в TempData будут сохранены даже после второго запроса, если их не прочитали. Для сохранения данных и после чтения будет предоставлен метод Keep, который позволит продлить жизнь данных в TempData;

□ асинхронные контроллеры, представленные в библиотеке MVC Futures, будут включены в финальный вариант ASP.NET MVC 2;

□ появится возможность создавать и использовать несколько провайдеров валидации, серверной и клиентской;

□ появится возможность перегружать создание TempDataProvider с помощью нового метода CreateTempDataProvider в классе Controller.

Заключение

ASP.NET MVC развивается значительными темпами, что показал период времени, за который была написана эта книга. За это время вышло несколько версий ASP.NET MVC 2, каждая из которых привнесла новый богатый функционал и изменила к лучшему старый.

ASP.NET MVC— это молодой, но мощный Framework, и если его развитие продолжится теми же темпами, которыми он развивается сейчас, то вскоре ASP.NET MVC станет мощнейшим инструментом разработки веб-сайтов, включающим в себя как средства для создания чистого быстрого кода для небольших проектов, так и средства, востребованные в корпоративной среде. Кроме того, поддержка Ajax, асинхронного выполнения, областей и улучшенная безопасность — это то, чего стоит ждать в финальной версии MVC 2 — следующей версии Framework.

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

ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ 1

Настройка среды для хостинга решений на MVC Framework

Задача хостинга приложений, написанных с помощью ASP.NET MVC, решается так же просто, как и задача хостинга обычных ASP.NET-приложений. На сегодняшний момент все компании, предоставляющие услуги хостинга, заявляют о поддержке ASP.NET MVC. На практике же поддержка ASP.NET MVC — это всего лишь маркетинговый ход, который позволяет добавить еще одну строчку в рекламный проспект. Так как сайты ASP.NET MVC могут работать везде, где работают обычные ASP.NET-сайты, никакой особой поддержки для ASP.NET MVC не требуется.

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

Настройка маршрутизации

Для правильного функционирования механизма маршрутизации в ASP.NET MVC необходима корректная обработка сервером IIS расширений mvc, пути с которыми используются внутри MVC Framework. Эта проблема, если она возникла, довольно просто решается в случаях, когда вы имеете дело с хостингом на базе IIS7 (сегодня это наиболее распространенный вариант). Для решения проблемы вам необходимо с помощью административной панели инструментов, которую предлагает ваша хостинговая компания, установить режим работы приложения в IIS7 Integrated Mode вместо установленного по умолчанию режима IIS7 Classic Mode. Варианты доступа к этой опции могут отличаться в зависимости от хостера.

Если же вы имеете доступ к серверу IIS, то изменение режима работы IIS7 для вашего приложения выполняется через инструмент Internet Information Services Manager. В IIS Manager вам достаточно задать верный пул приложений для своего приложения, который бы работал в режиме IIS7 Integrated Mode, по умолчанию это Default Application Pool или DefaultAppPool (рис. П1.1).

Проблема маршрутизации особенно актуальна для хостинга ASP.NET MVC-приложений на IIS6, в котором необходимо проделать дополнительные действия.

Если вы имеете доступ к IIS-серверу и можете его конфигурировать (в случаях, когда вы производите самостоятельный хостинг или хостинг на виртуальных серверах), вам необходимо самостоятельно зарегистрировать для IIS6 обработку расширения mvc. Это можно проделать двумя способами.

□ Вы можете использовать скрипт register.wsf, который поставляется с ASP.NET MVC и расположен по адресу C:\Program Files\Microsoft ASP.NET\ASP.NET MVC\Scripts или C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC\Scripts для 64-битных операционных систем. Скрипт register.wsf автоматически зарегистрирует обработку расширения mvc для IIS6.

□ Вместо использования скрипта вы можете проделать необходимые для регистрации действия собственноручно. Для этого необходимо пройти в свойства проекта, выбрать вкладку Virtual Directory и в ней нажать кнопку Configuration. В окне конфигурации приложения будет показан список привязок расширений к ISAPI-обработчикам. Добавьте новое расширение mvc и привяжите его к обработчику c:\WINDOWS\Microsoft.NET \Framework\v2.0.50727\aspnet_isapi.dll. Путь к обработчику ISAPI может отличаться, но вы можете определить верный, найдя сопоставленный путь для расширения aspx. После добавления обработчика вы увидите его в списке сопоставлений (рис. П1.2).

Рис. П1.2. Список сопоставлений расширений и ISAPI-обработчиков

□ После сопоставления расширения mvc для вашего приложения необходимо видоизменить создание маршрутов в Global.asax так, как показано в листинге П1.1.

Листинг П1.1. Модифицированный код Global.asax

using System;

using System.Collections.Generic;

using System.Linq; using System.Web;

using System.Web.Mvc;

using System.Web.Routing;

namespace MvcApplicationl {

public class MvcApplication : System.Web.HttpApplication

{

public static void RegisterRoutes(RouteCollection routes)

{

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

routes.MapRoute(

"Default",

"{controller}.mvc/{action}/{id}",

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

);

routes.MapRoute(

"Root",

"",

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

);

}

protected void Application_Start()

{

RegisterRoutes(RouteTable.Routes);

}

}

}

Обратите внимание на выделенные участки кода листинга П1.1. Вместо создаваемого по умолчанию маршрута с шаблоном {controller}/{action}/{id}, для IIS6 необходимо создать маршрут с шаблоном {controller}.mvc/{action}/{id}. Плюс, для обработки запросов к корню приложения необходимо создать еще один маршрут с именем Root и пустым шаблоном маршрута.

После таких изменений каждый запрос к вашему приложению должен иметь вид {controller}.mvc/{action}/{id}, т. е. каждая строка имени контроллера должна заканчиваться с расширением mvc. Например: запрос /product.mvc/details/1 вызовет контроллер-действие Details в контроллере Product и передаст в параметр id значение 1.

В случае, когда вы не имеете доступа к конфигурированию сервера IIS и не можете задать сопоставление расширения и ISAPI-обработчика, то решением может стать использование вместо расширения mvc другого расширения, зарегистрированного в системе: axd, aspx, ashx. В таком случае описанный в листинге код должен быть модифицирован следующим образом:

routes.MapRoute(

"Default",

"{controller}.aspx/{action}/{id}",

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

);

Это означает, что все ваши запросы должны представлять собой подобие запроса /product.aspx/details/1 с расширением aspx для имени контроллера.

Ограничение IIS6 приводит к тому, что маршрутизация и строки URL-запросов к вашему приложению не будут выглядеть так же красиво, как в приложениях, работающих на базе IIS7. Кроме того, вам будет необходимо генерировать совместимые ссылки с определенными маршрутами и используемыми в них расширениями (mvc или aspx). Однако в настоящее время использование серверов IIS6 в компаниях, которые предлагают услуги хостинга, стремится к нулю, и все крупные хостеры уже предлагают хостинг на базе IIS7 или даже IIS7.5. Поэтому, перед тем как сделать выбор хостера, уточните, предлагает ли он сервер на базе IIS7, и если обнаружится, что он по какой-то причине до сих пор этого не делает, то, возможно, вам следует поискать другого, более современного хостера.

ПРИЛОЖЕНИЕ 2

Оптимизация производительности

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

Здесь мы дадим некоторые базовые советы по оптимизации как производительности приложений на сервере, так и на клиентской стороне в браузере пользователя.

Кэширование данных

Одним из базовых инструментов повышения производительности является кэширование сгенерированных данных, в основном, веб-страниц. В ASP.NET существует базовый инструмент кэширования данных с помощью директивы @outputcache, параметры которой позволяют управлять временем кэширования страницы и задавать условия, при которых кэширование происходит.

В ASP.NET MVC для кэширования результатов выполнения действий в контроллерах предлагается использовать специальный атрибут outputcacheAttribute, который представляет собой аналог директивы @outputcache. Например, далее представлен код, который позволяет кэшировать все результаты контроллера на 30 минут:

[OutputCache(Duration = 1800, VaryByParam = "none")]

public class AdminController : Controller

Подробнее параметры этого атрибута рассмотрены в главе 4.

С помощью атрибута OutputCacheAttribute вы можете решить проблему загруженного запросами сервера. Кэшированный результат запроса имеет определенный срок жизни, в течение которого вместо вторичного получения результата в ответ на запрос возвращается кэшированное значение. Иными словами, кэширование позволяет нам снизить нагрузку на ресурсы сервера путем возвращения одного и того же результата на разные запросы клиентов. Более того, механизм кэширования работает так, что браузер пользователя также кэширует результат и будет брать информацию о странице при повторном обращении из своего локального кэша, а не путем отправки запроса на сервер.

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

Сжатие данных

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

Сервер IIS, на котором работают приложения ASP.NET MVC, предлагает комплексный механизм, позволяющий на лету сжимать исходящие данные из сервера и принимать сжатые данные от клиента. Для включения этого механизма в IIS7 можно воспользоваться опцией Compression, в которой можно включить сжатие как статического (скрипты, CSS-стили), так и динамического контента.

В случае, если включение динамического сжатия недоступно, следует включить его поддержку через панель добавления инструментов Windows (рис. П2.1).

Сжатие данных, передаваемых между клиентом и сервером, работает следующим образом:

1. Клиент отправляет запрос серверу, в заголовке которого может передать информацию о том, что он поддерживает сжатие данных. Этот заголовок передается следующим образом: Accept-Encoding: gzip, deflate.

2. IIS-сервер, получив такой заголовок, уверен, что клиент может обрабатывать сжатые данные, поэтому, если разработчик настроил сервер на сжатие данных, результат запроса будет сжат с помощью алгоритма GZip или Deflate и отправлен клиенту со следующим опознавательным заголовком: Content-Encoding: gzip.

3. Клиентский браузер, получив данные с заголовком Content-Encoding: gzip, понимает, что данные сжаты и, используя свои встроенные механизмы, распаковывает их, чтобы отобразить результат запроса пользователю.

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

Уменьшение размера передаваемых файлов

Часто даже использование сжатия данных посредством сервера IIS не приносит требуемого результата по снижению объема передаваемых данных. Кроме того, сжатие не работает и не дает никакого эффекта с клиентами, которые его не поддерживают. В таких случаях требуется обратить внимание на сами передаваемые данные, в особенности данные из статических файлов: JavaScript-скриптов, CSS-стилей, файлов изображений и др.

Уменьшение JavaScript

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

Одним из таких инструментов по уменьшению размера JavaScript-файлов является Microsoft Ajax Minifier.

Примечание

Инструмент Microsoft Ajax Minifier бесплатен и может быть свободно скачен по адресу:

http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34488.

*************************

Microsoft Ajax Minifier поставляется в виде утилиты командной строки вместе с документацией и отдельной сборкой, которая позволяет использовать функционал Microsoft Ajax Minifier в ваших собственных приложениях.

Использовать Microsoft Ajax Minifier просто. Например, следующая команда сожмет содержимое файла inputfilejs:

ajaxmin inputfile.js

Для вывода результата сжатия в другой файл потребуется добавить параметр -o:

ajaxmin inputfile.js -o outputfile.js

Кроме того, Microsoft Ajax Minifier имеет еще целый ряд параметров для тонкой настройки механизма сжатия JavaScript и представления результата. Ознакомиться со всеми доступными параметрами можно, запустив без параметров приложение ajaxmin из командной строки.

Минимизация и сжатие JavaScript-файлов может значительно сократить размер передаваемых от сервера к клиенту данных. Так, например, минимизация исходного кода библиотеки jQuery позволяет сократить ее размер с 125 до 53 Кбайт.

Уменьшение CSS

JavaScript-файлы, как и файлы со стилями CSS, могут быть сжаты для уменьшения размера передаваемых данных. Для решения задачи минимизации CSS-файлов существует ряд инструментов, самый популярный из которых CSSTidy.

Примечание

CSSTidy можно скачать по адресу http://csstidy.sourceforge.net/.

***********************

Использование CSSTidy по заверениям и тестам авторов может дать в среднем 33 % сжатия файлов со стилями. Для управления работой инструмента у него присутствует ряд параметров. Для минимизации файла достаточно указать его имя как параметр:

csstidy mycssfile.css

Для записи результата в другой файл необходимо указать имя выходного файла в виде второго параметра:

csstidy mycssfile.css myoutputfile.css

Остальные параметры можно получить, запустив csstidy без параметров.

Уменьшение изображений

Поскольку изображения — это важная часть почти каждого веб-сайта в Интернете, уменьшение размера изображений может принести значительный прирост производительности при передаче данных от сервера к клиенту.

Для оптимизации разных типов изображений можно воспользоваться разнообразными инструментами:

□ для уменьшения файлов изображений типа PNG без потери качества можно использовать популярный инструмент pngcrush (адрес проекта в Интернете http://pmt.sourceforge.net/pngcrush/);

□ для уменьшения и оптимизации файлов формата JPEG используется другой инструмент — jpegtran (скачать можно по адресу http://jpegclub.org/), который позволяет, используя свойства JPEG, достигать более высокого уровня сжатия изображения;

□ для оптимизации GIF-изображений можно первоначально перевести их в PNG-формат с помощью инструмента gif2png (скачать можно по адресу http://www.catb.org/~esr/gif2png/). В случае, когда GIF-файлы анимированы, их можно оптимизировать с помощью инструмента GIFsicle (скачать можно по адресу http://www.lcdf.org/gifsicle/).

Кроме программных инструментов по оптимизации изображений на компьютере есть ряд онлайн-ресурсов, которые позволяют сделать это так же эффективно. Одним из таких ресурсов является Smush.It от компании Yahoo!, который расположен по адресу http://developer.yahoo.com/yslow/smushit/.

Другие способы клиентской оптимизации

Кроме описанных ранее способов основной оптимизации есть еще несколько возможностей по увеличению отзывчивости и скорости работы вашего сайта.

Уменьшение количества запросов

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

□ собирайте все CSS-стили, используемые на странице, в один файл вместо использования нескольких отдельных CSS-файлов;

□ в случае, если код CSS-стилей небольшой по объему, рассмотрите возможность внедрения стилей в тело страницы вместо использования отдельного CSS-файла;

□ то же самое относится и к JavaScript-файлам, старайтесь избегать наличия нескольких JavaScript-файлов, вместо этого сведите их количество к минимуму;

□ все внешние статические ресурсы, такие как изображения, скрипты или стили, имеет смысл загружать со специального выделенного сервера, снижая нагрузку с основного сервера приложения;

□ в случае, когда нет возможности внедрить дополнительный сервер для статических ресурсов, рассмотрите возможности использования сторонних CDN-серверов для разного рода ресурсов. Например, скрипты jQuery могут быть загружены со специальных высокопроизводительных серверов Google или Microsoft. C серверов Microsoft можно загружать и многие другие скрипты: ASP.NET Ajax или jQuery Validation.

Уменьшение количества запросов на сервер не только разгрузит вам сервер, но и увеличит для вашего пользователя ощущение отзывчивости сайта.

Отказ от перенаправлений

Каждое перенаправление запроса (redirect) увеличивает для посетителя вашего сайта время ожидания. Старайтесь избегать перенаправлений и сведите их использование к минимуму или вовсе откажитесь от них.

Использование CSS Sprites

Техника спрайтов — это распространенная техника клиентской оптимизации работы с изображениями. Суть техники состоит в том, чтобы объединить набор небольших изображений в одно большое, чтобы впоследствии отображать куски этого изображения с помощью CSS-свойства background-position.

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

Примечание

Подробное рассмотрение механизма спрайтов выходит за рамки этой книги. Однако мы должны отметить, что поддержка спрайтов, вероятно, будет включена в следующие версии ASP.NET MVC или AsP.NET MVC Futures.

**************************

Размер cookie

Так как cookie передаются с каждым запросом от клиента к серверу, следует избегать устанавливать на клиенте больших размеров cookie. Каждый элемент cookie может содержать до нескольких килобайт информации. Поэтому несколько таких элементов могут значительно увеличить поток данных. Здесь действует только одно правило: избегайте сохранения данных в cookie без особой нужды.

Заключение

Тенденции современного Интернета таковы, что значительная часть функционала переносится с сервера на браузер пользователя. Страницы сайта, которые ранее служили для простого отображения информации, теперь все чаще наполняются насыщенным JavaScript-кодом. В связи с ростом роли клиентского кода, вопросы клиентской оптимизации становятся все более важными.

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

ПРИЛОЖЕНИЕ 3

Ресурсы по MVC Framework

Официальный сайт книги — www.mvcfw.ru.

На сайте публикуются дополнительные материалы для дальнейшего изучения и практического применения MVC Framework.

Официальный сайт MVC Framework — www.asp.net/mvc/.

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

Исходный код расширений ASP.NET — aspnet.codeplex.com.

На сайте представлен исходный код проектов, расширяющих возможности ASP.NET, а также полный архив исходного кода всех версий MVC Framework. Сайт на английском языке.

Content

Гайдар Магдануров Владимир Юнев
ASP.NET MVC Framework

ГЛАВА 1 Знакомство с MVC Framework

Паттерн проектирования MVC

История паттерна проектирования MVC

Преимущества подхода разработки MVC

1. Полный контроль над кодом разметки

2. Расширяемость

3. Простота автоматического тестирования

Установка MVC Framework

Первое приложение на MVC Framework

Структура MVC-приложения

Папка Content

Папка Controllers

Папка Models

Папка Scripts

Папка Views

Файл Default.aspx

Файл Global.asax

Файл Web.config

Обработка запросов MVC-приложением

Компоненты MVC-приложения

Таблица маршрутизации

Контроллер

Представление

Подход к разработке MVC-приложений

Заключение

ГЛАВА 2 MVC Framework и WebForms

Сравнение WebForms и MVC Framework

Технология WebForms

Преимущества WebForms

Недостатки WebForms

Технология MVC Framework

Преимущества MVC Framework

Недостатки MVC Framework

Выбор подхода к разработке веб-приложения

Реализация подхода MVC в WebForms

Совмещение WebForms и MVC Framework в рамках одного веб-приложения

Использование элементов управления WebForms в MVC-приложениях

Внедрение страниц WebForms в MVC-приложения

Использование MVC Framework в существующих решениях WebForms

Заключение

ГЛАВА 3 Модель и доступ к данным

Технология LINQ

LINQ для SQL

Entity Framework

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

Возможность замены источника данных

Реализация слоя данных

Пример использования слоя данных

Механизмы для работы с данными

XML-данные

Работа с данными через ADO.NET

LINQ для SQL

Entity Framework

NHibernate

Сравнение механизмов доступа к данным

Рекомендации по выбору механизма доступа к данным

ГЛАВА 4 Контроллеры

Назначение контроллеров Обзор контроллеров в ASP.NET MVC

Простой пример реализации контроллера

Архитектура контроллеров

Порядок вызова архитектурных механизмов

Фабрика контроллеров

Действия, фильтры и атрибуты

Переопределение свойства Actionlnvoker

Атрибуты ActionMethodSelectorAttribute

Атрибуты, производные от FilterAttribute

AuthorizeAttribute

HandleErrorAttibute

ValidateAntiForgeryTokenAttribute

ValidateInputAttribute

Атрибуты ActionFilterAttribute и OutputCacheAttribute

Стандартные реализации класса ActionResult

ViewResult

JsonResult

FileResult

RedirectResult и RedirectToRouteResult

ContentResult

EmptyResult

Создание своей реализации ActionResult

Model Binding

Советы по использованию контроллеров

Атрибуты ActionNameSelectorAttribute и ActionNameAttribute

Наследование контроллеров

Асинхронное выполнение при работе с контроллерами

Паттерн IAsyncResult

Паттерн Event

Паттерн Delegate

Дополнительные сведения об асинхронных контроллерах

Неизвестные действия и метод HandleUnknownAction

ГЛАВА 5 Представление и интерфейс приложения

Стандартный механизм представлений на базе WebForms

Code-behind-файлы

Мастерские страницы и элементы управления

Файлы представлений в структуре проекта

Данные для отображения и ViewData

Строгая типизация данных представления

Поиск элементов в коллекции ViewData

Генерация разметки представлением

Вложенный управляющий код

<%= значение %>

<% управляющая конструкция %>

Вспомогательные методы

Кодирование текста и атрибутов

Гиперссылки на действия контроллеров

Html.ActionLink()

Html. RouteLink()

Элементы управления HTML-страницы

HTML-форма

Текстовые поля, скрытые поля и кнопки

Элементы-списки

Индикаторы корректности введенных данных

Создание собственного вспомогательного метода

Конкатенация строк

Использование ресурсов

Использование дополнительных слоев абстракции

Использование серверных элементов управления WebForms

Частичные представления

Создание гаджетов

Заключение

ГЛАВА 6 Механизмы маршрутизации

Маршрутизация в ASP.NET

Механизмы маршрутизации

Маршрут и класс Route

Коллекция маршрутов и класс RouteCollection

Таблица маршрутизации и класс RouteTable

Ограничения и интерфейс IRouteConstraint

Обработчик маршрутов и интерфейс IRouteHandler

Создание маршрутов

Наименование маршрута

RedirectToRoute

AjaxHelper

UrlHelper

Шаблон маршрута и свойство Url

Значения параметров маршрута по умолчанию и свойство Defaults

Ограничения параметров маршрута и свойство Constraints

Параметры маршрута и свойство DataTokens

Игнорирование маршрутов

Советы по использованию маршрутов

Маршруты и валидация запросов

Хранение маршрутов в базе данных

Маршрутизация и тестирование

Подготовка инструментов

Создание тестов

Утилита ASP.NET Routing Debugger

Заключение

ГЛАВА 7 Ajax-функциональность

История успеха Ajax

Современный Ajax

Пример использования Ajax

MVC Framework и Ajax

Ajax-функционал в MVC Framework

AjaxOptions

Ajax.BeginForm

Ajax.ActionLink

IsAjaxRequest

jQuery

Библиотека jQuery

jQuery API

Функции для работы с Ajax

jQuery.ajax

load

jQuery.get и jQuery.post

jQuery. getJSON

jQuery.getScript

jQuery. ajaxSetup

События Ajax в jQuery

Применение Ajax и jQuery в MVC Framework

Пример 1. Проверка логина при регистрации

Реализация на ASP.NET Ajax

Реализация на jQuery

Пример 2. Логин через Ajax

Реализация на ASP.NET Ajax

Реализация на jQuery

Полезные советы

Вопросы безопасности

Обработка пользовательских данных

Управление данными и cookie

Расширения jQuery

Выбор между ASP.NET Ajax и jQuery

Заключение

ГЛАВА 8 Тестирование веб-приложений

Установка и настройка NUnit

Создание и выполнение тестов

Несколько слов о важности тестирования

Тесты и MVC Framework

Заключение

ГЛАВА 9 ASP.NET MVC 2 и Visual Studio 2010

Области

Области для нескольких проектов

Области в одном проекте

Шаблонные помощники

Шаблоны по умолчанию

Создание шаблонов

Аннотация данных и валидация

Классы метаданных

Новые атрибуты

Http***Attribute и перегрузка типов запросов

DefauItValueAttribute

RequireHttpsAttribute

Улучшения в связывании данных

Прочие улучшения в API

Нововведения Visual Studio 2010

Мультитаргетинг в Visual Studio 2010

Поддержка нескольких мониторов

Сниппеты JavaScript, Html, ASP.NET в Visual Studio 2010

Что дальше?

Заключение

ПРИЛОЖЕНИЯ

ПРИЛОЖЕНИЕ 1 Настройка среды для хостинга решений на MVC Framework

Настройка маршрутизации

ПРИЛОЖЕНИЕ 2 Оптимизация производительности

Кэширование данных

Сжатие данных

Уменьшение размера передаваемых файлов

Уменьшение JavaScript

Уменьшение CSS

Уменьшение изображений

Другие способы клиентской оптимизации

Уменьшение количества запросов

Отказ от перенаправлений

Использование CSS Sprites

Размер cookie

Заключение

ПРИЛОЖЕНИЕ 3 Ресурсы по MVC Framework