Чтение онлайн

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="#" rel="stylesheet" type="text/css" />

</head>

<body>

<div class="page">

<div id="header">

<div id="title">

<h1>

Northwind

</h1>

</div>