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

public Func Foo(Guid? userId)

Для демонстрации реализации данного паттерна перепишем пример паттерна Event по-другому:

public Func 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. По сравнению с паттерном 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, может работать только с синхронными запросами.

Во время обработки клиентских запросов весьма распространенной ситуацией является невозможность определить действие, которое необходимо вызвать в ответ на запрос. Класс 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.

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

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

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

Модель использования 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:

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