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

[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,используемому для строгой типизации представлений, описанному далее.