Asp.net mvc framework
Шрифт:
Паттерн 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, и бизнес-логики самой страницы, выполненной в файле исходного кода.