Текст книги "Asp.net mvc framework"
Автор книги: Гайдар Магдануров
сообщить о нарушении
Текущая страница: 8 (всего у книги 17 страниц)
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
Для демонстрации реализации данного паттерна перепишем пример паттерна Event по-другому:
public Func
{
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
Дополнительные сведения об асинхронных контроллерах
Для асинхронных операций важно понятие времени исполнения запроса, поэтому в стандартный механизм класса 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
Файлы code-behind могут быть необходимы для представлений, использующих серверные элементы управления, требующих инициализации в различные моменты жизненного цикла страницы. Однако в подавляющем большинстве случаев такой дизайн приложений приводит к сложностям в поддержке проекта, не говоря уже о грубом нарушении подхода MVC.
Мастерские страницы и элементы управления
Из WebForms в механизм представлений в MVC пришел и подход к повторному использованию общей разметки страниц – мастерские страницы (master pages), файлы которых имеют расширение master. Мастерские страницы представляют собой инструмент для определения общего шаблона набора страниц, определяя общую разметку для набора контентных страниц и расположение блоков, содержащихся в контентных страницах.
Принцип построения мастерской страницы следующий:
1. Задается общий дизайн страницы и блоки, общие для набора страниц.
2. В разметке мастерской страницы определяются блоки, которые будут заполнены содержимым контентных страниц с помощью разметки:
Пример мастерской страницы приведен в листинге 5.1.
3. При создании разметки контентных страниц используются блоки:
где ContentPlaceHolderID соответствует тому фрагменту мастерской страницы, который помечен элементом ContentPlaceHolder с соответствующим свойством id. Пример контентной страницы приведен в листинге 5.2.
Листинг 5.1. Пример мастерской страницы
<%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Northwind
<% Html.RenderPartial("LogOnUserControl"); %>
Листинг 5.2. Пример контентной страницы
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>
о проекте
О проекте
Тут что-то написано.
Мастерские страницы могут быть вложенными, т. е. в свою очередь использовать мастерские страницы. Это может быть полезно, когда существует общая планировка всех страниц на сайте (родительская мастерская страница) и несколько вариантов планировки дизайна вложенных разделов (дочерние мастерские страницы).
На контентной странице могут быть заданы несколько блоков 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) {
%>
Добро пожаловать <%= Html.Encode(Page.User.Identity.Name)
%>!
[ <%= 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
Поскольку ViewData является коллекцией доступных по строковому ключу объектов, в ней может быть сохранено произвольное количество объектов разных типов.
public ActionResult ViewDataDemo()
{
ViewData.Add("Hello", "World");
ViewData["Date"] = DateTime.Now;
return View();
}
Объекты, содержащиеся в коллекции ViewData, в свою очередь, могут быть использованы в разметке представления.
<%= ((DateTime)ViewData["Date"]).ToLongTimeString() %>
Строгая типизация данных представления
Работа с произвольным набором элементов удобна, когда набор данных, отображаемых представлением, меняется в процессе развития проекта. Однако в случаях, когда все данные представления могут быть описаны одним классом, значительно удобнее использовать строго типизированные представления. Для этого коллекция ViewData предоставляет свойство ViewData.Model и возможность строгой типизации представления путем наследования самого класса представления от класса ViewPage
Листинг 5.4. Представление ViewDataModelStronglyTyped.aspx
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage
ViewDataModelStronglyTyped
ViewDataModelStronglyTyped
С точки зрения контроллера, для работы со строго типизированным представлением достаточно присвоить объект свойству 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
CustomerCustomerDemos {get; set;}
public EntitySet
}
Данные передаются контроллером 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" %>
ContentPlaceHolderID="TitleContent" runat="server"> Домашняя страница
<%= Html.Encode(ViewData ["Message"]) %>
|
Название компании
|
Контактное лицо
|
|---|---|
|
<%= c.CompanyName %>
|
<%= c.ContactName %>
|
В результате выполнения примера приведенное ранее представление будет отображено в виде, показанном на рис. 5.1.
В тексте листинга 5.6 управляющие конструкции выделены полужирным шрифтом.
Как было отмечено ранее, при создании разметки представления могут быть использованы два типа управляющих конструкций, описанные далее.
<%= значение %>
Конструкция вида <%= значение %> используется для вывода значений в результирующий код HTML-разметки. Тип значения может быть любым, который может быть приведен к строке. Значение будет выведено именно в том месте разметки, в котором оно размещено.
<% управляющая конструкция %>
Управляющие инструкции позволяют проверять выполнение некоторых условий для вывода той или иной HTML-разметки (условия) либо многократно повторять фрагменты HTML-разметки (циклы).
Оформляются управляющие конструкции по приведенному далее шаблону.
<% инструкция (условия) { %>
Произвольный HTML-код, который может
перемежаться другими
управляющими инструкциями
<% } %>
Пример использования цикла приведен в листинге 5.6, применение условий выглядит аналогично:
<% if (Request.IsAuthenticated) { %>
Добро пожаловать
<%= Html.Encode(Page.User.Identity.Name) %>!
[ <%= Html.ActionLink("Выход", "LogOff", "Account") %> ]
<%
} else {
%>
[ <%= Html.ActionLink("Вход", "LogOn", "Account") %> ]
<% } %>
Вспомогательные методы
Вспомогательные методы класса HtmlHelper, доступного как свойство Html для представлений и частичных представлений, уже неоднократно встречались в коде ранее. Теперь пришла пора рассмотреть подробнее, какую функциональность они несут и какие задачи решают.
Вспомогательные методы применяются тогда, когда необходимо многократно использовать какую-либо функциональность – от генерации часто применяемой разметки до реализации функциональности элементов управления, таких как кнопки, текстовые поля, гиперссылки и т. д.
Вспомогательным методом может быть любой статический метод, доступный на уровне представления, однако для упрощения общей структуры проектов MVC их принято группировать в рамках класса HtmlHelper. В табл. 5.1 приведен список основных вспомогательных методов класса HtmlHelper.
