Фаулер М. Архитектура корпоративных программных приложений

Подождите немного. Документ загружается.

354 Часть II. Типовые решения

request.setAttribute("helper",

new ArtistHelper(artist));

forward("/artist.jsp", request, response); } }

Хотя данный пример очень прост, он демонстрирует основные этапы обработки за-

проса. Вначале контроллер создает необходимые объекты моделей (здесь их функция за-

ключается только в том, чтобы найти объект, который необходимо отобразить). Затем он

помещает в HTTP-запрос нужную информацию (в нашем примере это вспомогательный

объект), чтобы представление JSP смогло правильно выполнить отображение найденных

сведений. И наконец, контроллер передает обработку отображения представлению по

шаблону. Передача обработки отображения представляет собой поведение, общее для

всех контроллеров страниц, а потому может быть реализована в их суперклассе.

class ActionServlet...

protected void forward(String target,

HttpServletRequest request, HttpServletResponse

response) throws IOException, ServletException

{

RequestDispatcher dispatcher =

getServletContext().getRequestDispatcher(target);

dispatcher.forward(request, response);

}

Основная точка соприкосновения между представлением по шаблону и контроллером

страниц— это имена параметров, указанных в запросе, значения которых должны быть

переданы всем объектам, используемым представлением JSP.

Логика контроллера в данном примере действительно очень проста, однако даже при

ее усложнении наш сервлет все еще может быть использован в качестве контроллера. На-

пример, можно реализовать похожее поведение для отображения сведений об альбомах

таким образом, что альбомам классической музыки будут соответствовать свой объект

модели и свое представление JSP. Для реализации этого поведения используется еще

один производный класс контроллера.

class AlbumController. . .

public void doGet(HttpServletRequest request,

HttpServletResponse response)

throws IOException, ServletException

{

Album album = Album.find(request.getParameter("id") ) ;

if (album == null) {

forward C'/missingAlbumError.jsp", request, responses-

return; }

request.setAttribute("helper", album);

if (album instanceof ClassicalAlbum)

forward("/classicalAlbum.jsp", request, response);

Глава 14. Типовые решения, предназначенные для представления данных в Web 355

else

forward("/album.jsp", request, response); }

Обратите внимание, что в этом примере я не создаю отдельный вспомогательный

класс, а использую в качестве вспомогательных объекты модели. Это можно делать тогда,

когда вспомогательный класс нужен только для того, чтобы передавать управление клас-

су модели. Тем не менее, если вы решите поступить подобным образом, убедитесь, что

класс модели не содержит никакого кода, зависимого от сервлета. В противном случае

весь этот код должен быть вынесен в отдельный вспомогательный класс.

Пример: использование страницы JSP в качестве обработчика запросов (Java)

В качестве контроллера страниц можно использовать сервлет, однако обычно в этой

роли выступает сама страница сервера. Недостаток данного подхода заключается в необ-

ходимости внедрения в страницу сервера кода скриптлета (а, как вы уже могли догадать-

ся, я считаю, что код скриптлета имеет такое же отношение к качественному проектиро-

ванию, как армрестлинг — к профессиональному спорту).

Несмотря на это, страницу сервера действительно можно применять в качестве обра-

ботчика запросов, перекладывая фактическое выполнение всех функций контроллера на

вспомогательный объект. Я сделаю это для отображения сведений об альбоме, используя

адрес URL вида http: //localhost: 8080/isa/album. jsp?id=zero. БОЛЬШИНСТВО

альбомов будут отображаться с помощью представления album. j sp, а альбомы с класси-

ческой музыкой — с помощью представления classicalAlbum. jsp.

Поведение контроллера реализовано во вспомогательном классе, имя которого зада-

ется в коде самой страницы album. j sp.

album.j sp...

<j sp:useBean id="helper" class="actionController.AlbumConHelper

V'/>

<%helper.init(request, response);%>

Вызов метода инициализации настраивает вспомогательный объект на выполнение

функций контроллера.

class AlbumConHelper extends HelperController...

public void init(HttpServletRequest request,

'bHttpServletResponse response) {

super.init(request, response);

if (getAlbum() == null) forward("missingAlbumError.jsp",

^request, response);

if (getAlbum() instanceof ClassicalAlbum) {

request.setAttribute("helper", getAlbum());

forward("/classicalAlbum.jsp", request, response); } }

356 Часть II. Типовые решения

Поведение, общее для всех контроллеров, можно вынести в суперкласс вспомога-

тельного объекта.

class HelperController...

public void init (HttpServletRequest request,

HttpServletResponse response) { this.request =

request; this.response = response; } protected

void forward(String target,

HttpServletRequest request,

HttpServletResponse response) {

try {

RequestDispatcher dispatcher =

request.getRequestDispatcher(target) ;

if (dispatcher == null) response.sendError(

response.SC_NO_CONTENT) ;

else dispatcher.forward(request, response);

} catch (IOException e) {

throw new ApplicationException (e); }

catch (ServletException e) {

throw new ApplicationException (e); } }

Обратите внимание на разницу в поведении контроллера-сервлета и контроллера —

вспомогательного объекта. В последнем случае страница JSP, выступающая в роли обра-

ботчика запросов, одновременно является и стандартным представлением, а потому

управление возвращается первоначальной странице сервера (кроме случая, когда оно пе-

редается другому представлению). Это очень удобно, когда большинство страниц JSP не-

посредственно выступают в роли представлений и передавать обработку отображения

другим представлениям не нужно. Метод инициализации вспомогательного объекта за-

пускает поведение модели и настраивает все параметры, необходимые для последующего

отображения результатов. Данная схема вполне естественна, поскольку многие ассоции-

руют Web-страницу со страницей сервера, которая применяется для представления этой

Web-страницы. Кроме того, зачастую подобная схема хорошо согласуется с конфигура-

цией Web-сервера.

Вызывать метод инициализации вспомогательного объекта довольно неудобно. В сре-

де JSP это можно значительно упростить с помощью класса пользовательского дескрип-

тора (custom tag). Такой дескриптор может автоматически создать нужный объект, по-

местить его в запрос и инициализировать. Все, что для этого нужно, — вставить в страни-

цу JSP простой дескриптор примерно следующего вида:

<helper:init name = "actionController.AlbumConHelper"/>

Теперь вся работа по инициализации вспомогательного объекта ложится на реализа-

цию класса пользовательского дескриптора.

Глава 14. Типовые решения, предназначенные для представления данных в Web 357

class HelperlnitTag extends HelperTag...

private String helperClassName;

public void setName(String helperClassName) {

this.helperClassName = helperClassName;

}

public int doStartTag() throws JspException {

HelperController helper = null; try {

helper = (HelperController)

Class.forName(helperClassName).newlnstance(); }

catch (Exception e) {

throw new ApplicationException("Unable to

instantiate " + helperClassName, e) ; }

initHelper(helper);

pageContext.setAttribute(HELPER, helper);

return SKIP_BODY; }

private void initHelper(HelperController helper) {

HttpServletRequest request = (HttpServletRequest)

pageContext.getRequest(); HttpServletResponse

response = (HttpServletResponse)

pageContext.getResponse() ;

helper.init(request, response); }

class HelperTag...

public static final String HELPER = "helper";

Я могу создать еще один производный класс дескриптора, который будет применять-

ся для доступа к свойству вспомогательного объекта (в нашем примере это будет назва-

ние альбома).

class HelperGetTag extends HelperTag...

private String propertyName;

public void setProperty(String propertyName) {

this.propertyName = propertyName;

}

public int doStartTag() throws JspException {

try {

pageContext.getOut().print(getProperty(propertyName)); )

catch (IOException e) {

throw new JspException("unable to print to writer");

}

return SKIP_BODY;

}

class HelperTag...

protected Object getProperty(String property)

throws JspException {

358 Часть II. Типовые решения

Object helper = getHelper();

try {

final Method getter =

helper.getClass().getMethod(

^gettingMethod(property), null);

return getter.invoke(helper, null); }

catch (Exception e) {

throw new JspException ("Unable to invoke " +

gettingMethod(property) + " - " + e.getMessage());

} } private Object getHelper() throws

JspException {

Object helper = pageContext.getAttribute(HELPER); if

(helper == null) throw new JspException( "Helper not

found.");

return helper; } private String

gettingMethod(String property) {

String methodName = "get" + property.substring(

0, 1).toUpperCase() + property.substring(1);

return methodName; }

(Кое-кто из вас может возразить, что в данном примере было бы удобнее использо-

вать механизм Java Beans, который бы позволил просто вызвать get-метод посредством

отражения. Те, кто так думает, конечно же, правы... и, должно быть, достаточно умны

для того, чтобы реализовать это самостоятельно.)

Определив объект HelperGetTag, я могу использовать его для извлечения информа-

ции из вспомогательного объекта. Для этого в страницу JSP придется вставить еще один

дескриптор — между прочим, довольно короткий (что устранит вероятность неправиль-

ного написания имени вспомогательного объекта).

Пример: обработка запросов страницей сервера с применением механизма

разделения кода и представления (С#)

Компоненты .NET, предназначенные для создания Web-приложений, ориентирова-

ны на работу с контроллером страниц и представлением по шаблону, хотя, разумеется, вы

можете обрабатывать Web-события и по-другому. В этом примере я воспользуюсь стан-

дартным подходом .NET, накладывая слой представления на слой домена с использова-

нием модуля таблицы (Table Module, 148), а также применяя объекты DataSet в качестве

"переносчиков" информации между слоями.

На этот раз будем иметь дело со страницей, которая отображает количество и интен-

сивность перебежек за одну подачу в крикетном матче. Конечно же, не все читатели мо-

гут быть знакомы с правилами этой поистине королевской игры. Впрочем, для нашего

примера будет достаточно, что количество перебежек (runs scored) — это количество

очков, набранное игроком, отбивающим мяч (бэтсменом), а интенсивность перебежек

(run rate) — это количество перебежек, деленное на количество отбитых мячей. Сведения

Глава 14. Типовые решения, предназначенные для представления данных в Web 359

о количестве перебежек и количестве отбитых мечей хранятся в базе данных. Интенсив-

ность перебежек вычисляется приложением — небольшой, но крайне полезный в плане

обучения кусочек логики домена.

В качестве обработчика запросов будем использовать Web-страницу ASP.NET, хра-

нящуюся в файле с расширением .aspx. Как и другие подобные конструкции, данный

файл позволяет внедрять логику домена прямо в код страницы сервера с помощью

скриптлетов. Как вы уже знаете, я скорее выпью плохое пиво, чем стану писать скрипт-

леты. Поэтому воспользуемся механизмом разделения кода и представления (code behind),

который позволяет ассоциировать страницу ASP.NET с обычными классами, указав имя

соответствующего файла в заголовке страницы.

<%@ Page language="c#" Codebehind="bat.aspx.cs"

AutoEventWireup="false" trace="False"

Inherits="batsmen.BattingPage" %>

Данная страница "наследует" класс BattingPage, реализующий логику домена, и по-

тому может использовать все его защищенные свойства и методы. В этом случае объект

страницы является обработчиком запросов, а фактическое выполнение логики домена

будет осуществляться посредством метода Page_Load. Если большинство страниц будут

обрабатывать запросы аналогичным способом, я могу определить супертип слоя (Layer

Supertype, 491) с шаблонным методом Page_Load [20].

class CricketPage...

protected void Page_Load(object sender, System.EventArgs e) {

db = new OleDbConnection(DB.ConnectionString); if

(hasMissingParameters())

errorTransfer (missingParameterMessage);

DataSet ds = getDataO; if (hasNoData (ds))

errorTransfer ("No data matches your request");

applyDomainLogic (ds); DataBindO ; prepareUI(ds); }

Шаблонный метод разбивает обработку запроса на несколько основных этапов.

Это позволяет определить общий принцип обработки Web-запросов и в то же время реа-

лизовать в каждом контроллере страниц собственные варианты выполнения тех или иных

этапов. В этом случае при написании нескольких контроллеров страниц вы будете знать,

какие методы необходимо реализовать для подстановки в шаблонный метод. Если же ка-

кой-то странице понадобится выполнить нечто совершенно другое, она всегда сможет

переопределить метод Page_Load.

Вначале нужно проверить правильность значений параметров, переданных пользова-

телем странице ASP.NET. В реальных приложениях это могло бы потребовать общей

проверки значений на отсутствие тривиальных ошибок, однако в данном случае просто

проанализируем URL вида http://localhost/batsmen/bat.aspx?team=England&

innings=2&match=905 и проверим, присутствуют ли в нем все параметры, необходимые

для выполнения запроса к базе данных. Как обычно, я слишком упрощаю обработку

360 Часть II. Типовые решения

ошибок, по крайней мере до тех пор, пока кто-нибудь не разработает хороших типовых

решений для выполнения проверки на правильность. Итак, наша страница будет опреде-

лять набор обязательных параметров, а супертип слоя выполнять проверку их наличия.

class CricketPage...

abstract protected String[] mandatoryParameters();

private Boolean hasMissingParameters() {

foreach (String param in mandatoryParameters())

if (Request. Params [param] == null) return truer-

return false; }

private String missingParameterMessage {

get {

String result = "<P>This page is missing mandatory

parameters:</P>";

result += "<UL>"; foreach (String param in

mandatoryParameters()) if (Request.Params[param]

== null)

result += String.Format("<LI>{0}</LI>", param); result

+= "</UL>"; return result; } }

protected void errorTransfer (String message) {

Context.Items.Add("errorMessage", message);

Context.Server.Transfer("Error.aspx" ) ; }

class BattingPage...

override protected String[] mandatoryParameters() {

String[] result = {"team", "innings", "match"};

return result;

}

Следующий этап — извлечение данных из базы данных и помещение их в объект

ADO.NET DataSet (напомню, что он применяется для доступа к данным в отсоединен-

ном режиме). В нашем примере все данные извлекаются посредством одного запроса к

таблице batting.

class CricketPage...

abstract protected DataSet getDataO;

protected Boolean hasNoData(DataSet ds) {

foreach (DataTable table in ds.Tables)

if (table.Rows.Count != 0) return false;

return true; }

class BattingPage...

override protected DataSet getDataf) {

Глава 14. Типовые решения, предназначенные для представления данных в Web 361

OleDbCommand command = new OleDbCommand(SQL, db) ;

command.Parameters.Add(new OleDbParameter("team", team));

command.Parameters.Add(new OleDbParameter("innings", Winnings));

command.Parameters.Add(new OleDbParameter("match",

match)) ;

OleDbDataAdapter da = new OleDbDataAdapter(command);

DataSet result = new DataSet (); da.Fill(result,

Batting.TABLE_NAME); return result; }

private const String SQL =

@"SELECT * from batting

WHERE team = ? AND innings = ? AND matchID = ?

ORDER BY battingOrder";

Теперь пришла очередь выполнения логики домена, организованной в модуль табли-

цы. Контроллер передает модулю таблицы извлеченное множество данных для после-

дующей обработки.

class CricketPage...

protected virtual void applyDomainLogic (DataSet ds) {}

class BattingPage...

override protected void applyDomainLogic (DataSet

dataSet) {

batting = new Batting(dataSet);

batting.CalculateRates(); }

На этом этапе выполнение обязанностей контроллера закончено. Теперь, как следует

из классической системы модель—представление—контроллер (Model View Controller, 347),

контроллер должен обратиться к представлению, чтобы передать ему обработку отобра-

жения. В нашем примере объект BattingPage выполняет роль и контроллера и пред-

ставления, поэтому вызов метода PrepareUl в конце метода Page_Load фактически яв-

ляется частью поведения представления. Итак, пока что я могу попрощаться с данным

примером. Однако смею надеяться, что вы не удовлетворены отсутствием эффектной

концовки. Не огорчайтесь — мы еще вернемся к обсуждению этого вопроса.

362 Часть II. Типовые решения

Контроллер запросов (Front Controller)

Контроллер, который обрабатывает все запросы к Web-caumy

Обработка запросов к Web-сайтам со сложной структурой подразумевает выполнение

большого количества аналогичных действий. Это проверка безопасности, обеспечение

поддержки интернационализации и открытие специальных представлений для особых

категорий пользователей. Если поведение входного контроллера будет разбросано по не-

скольким объектам, это приведет к дублированию большей части кода. Кроме того, это

значительно затруднит изменение поведения контроллера во время выполнения.

Типовое решение контроллер запросов объединяет все действия по обработке запро-

сов в одном месте, распределяя их выполнение посредством единственного объекта-

обработчика. Как правило, этот объект реализует общее поведение, которое может быть

изменено во время выполнения с помощью декораторов. Для выполнения конкретного

запроса обработчик вызывает соответствующий объект команды.

Принцип действия

Контроллер запросов обрабатывает все запросы, поступающие к Web-сайту, и обычно

состоит из двух частей: Web-обработчика и иерархии команд. Web-обработчик — это объ-

ект, который выполняет фактическое получение POST- или GET-запросов, поступив-

ших на Web-сервер. Он извлекает необходимую информацию из адреса URL и входных

данных запроса, после чего решает, какое действие необходимо инициировать, и делеги-

рует его выполнение соответствующей команде (рис. 14.2).

Web-обработчик обычно реализуется в виде класса, а не страницы сервера, поскольку

он не генерирует никаких откликов. Команды также являются классами, а не страница-

ми сервера; более того, им не нужно знать о наличии Web-окружения, несмотря на то что

Глава 14. Типовые решения, предназначенные для представления данных в Web 363

им часто передается информация из HTTP-запросов. В большинстве случаев Web-

обработчик — это довольно простая программа, функции которой заключаются в выборе

нужной команды.

Выбор команды может происходить статически или динамически. Статический вы-

бор команды подразумевает проведение синтаксического анализа адреса URL и приме-

нение условной логики, а динамический — извлечение некоторого стандартного фраг-

мента адреса URL и динамическое создание экземпляра класса команды.

Преимущества статического выбора команды состоят в использовании явного кода,

наличии проверки времени компиляции и высокой гибкости возможных вариантов на-

писания адресов URL. В свою очередь, использование динамического подхода позволяет

добавлять новые команды, не требуя изменения Web-обработчика.

Рис. 14.2. Принцип работы контроллера запросов

При динамическом выборе команд имя класса команды можно поместить непосред-

ственно в адрес URL либо воспользоваться файлом свойств, который будет привязывать

адреса URL к именам классов команд. Разумеется, это потребует создания дополнитель-

ного файла свойств, однако позволит легко и непринужденно изменять имена классов,

не просматривая все имеющиеся на сервере Web-страницы.

Контроллер запросов особенно хорошо сочетается с типовым решением перехваты-

вающий фильтр (Intercepting Filter), описанным в [3]. Последнее представляет собой деко-

ратор, выполняющий роль оболочки для Web-обработчика контроллера запросов и по-

зволяющий строить цепочки фильтров (filter chains), т.е. последовательности фильтров,

предназначенные для обработки таких процессов, как аутентификация, регистрация на

сайте и выбор кодировки. Использование фильтров позволяет динамически настраивать

их во время конфигурирования Web-сервера.

Роб Ми (Rob Мее) показал мне интересный вариант контроллера запросов, в котором

Web-обработчик состоял из двух частей: "вырожденного" обработчика и диспетчера. Вы-

рожденный Web-обработчик извлекает базовые данные из параметров HTTP-запроса и

передает их диспетчеру таким образом, что тот оказывается полностью независимым от