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

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

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

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

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

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

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

бражения результатов. Единственная обязанность обработчика — выбор той или иной

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

Назначение

Контроллер запросов имеет более сложную структуру, чем его очевидный соперник —

контроллер страниц (Page Controller, 350). Чтобы быть удостоенным внимания разработ-

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

разумеется, есть.

Во-первых, Web-сервер должен быть настроен на использование только одного кон-

троллера запросов; всю остальную работу по распределению запросов будет выполнять

Web-обработчик. Это значительно облегчит конфигурирование Web-сервера (особенно

если этот процесс достаточно трудоемок). Использование динамического выбора команд

позволяет добавлять новые команды без каких-либо изменений. Кроме того, динамиче-

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

ровать" обработчик в настройках сервера.

Поскольку для выполнения каждого запроса создаются новые экземпляры классов

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

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

граммированием; тем не менее вам придется следить за отсутствием совместного исполь-

зования других объектов, таких, как объекты модели.

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

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

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

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

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

мя выполнения с помощью многочисленных декораторов [20]. Декораторы могут приме-

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

тернационализации и т.п. Более того, их можно добавлять не только с помощью файла

настроек, но и прямо во время работы сервера. (Детальное описание этого подхода под

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

Дополнительные источники информации

В [3J содержится подробное описание реализации контроллера запросов на языке Java.

Там же описано типовое решение перехватывающий фильтр, которое весьма хорошо со-

четается с контроллером запросов.

Типовое решение контроллер запросов используется в целом ряде Web-инфраструктур

Java. Хороший пример такого использования приведен в [37].

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

Пример: простое отображение (Java)

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

ключительно оригинального и сверхважного задания — отображения сведений об исполни-

теле (рис. 14.3). Воспользуемся динамическим выбором команд, а также адресом URL ви-

да http://localhost:8080/isa/music?name=barelyWorks&command=Artist. Па-

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

для выполнения того или иного запроса.

Рис. 14.3. Классы, принимающие участие в реализации контроллера запросов

Начнем с разработчика, который реализован в виде сервлета.

class FrontServlet...

public void doGet(HttpServletRequest request,

^HttpServletResponse response)

throws IOException, ServletException { FrontCommand

command = getCommand(request);

command.init(getServletContext(), request, response);

command.process() ;

}

private FrontCommand getCommand(HttpServletRequest request) {

try {

return (FrontCommand) getCommandClass(

^request).newlnstance();

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

} catch (Exception e) {

throw new ApplicationException (e); }

private Class getCommandClass(HttpServletRequest request) {

Class result; final String commandClassName =

"frontController." +

(String) request.getParameter("command") +

"Command"; try {

result = Class.forName(commandClassName); }

catch (ClassNotFoundException e) {

result = UnknownCommand.class;

}

return result;

}

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

имя которого образовано путем конкатенации имени команды и слова Command. Когда

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

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

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

метры, например сеанс HTTP. На тот случай, если команда с указанным именем не будет

найдена, я использовал типовое решение частный случай (Special Case, 511) и возвратил

неизвестную команду (класс UnknownCommand). Как это обычно бывает, использование

частного случая позволяет избежать дополнительной проверки на наличие ошибок.

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

команд. Все эти объекты должны быть инициализированы с помощью информации, по-

лученной от Web-сервера.

class FrontCommand...

protected ServletContext context; protected

HttpServletRequest request; protected

HttpServletResponse response; public void

init(ServletContext context,

HttpServletRequest request,

HttpServletResponse response) {

this.context = context;

this.request = request;

this.response = response; }

Помимо этого, класс FrontCommand может реализовать общее поведение, например

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

определен конкретными классами команд.

class FrontCommand...

abstract public void process () throws ServletException,

IOException ;

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

protected void forward(String target)

throws ServletException, IOException {

RequestDispatcher dispatcher =

context.getRequestDispatcher(target) ;

dispatcher.forward(request, response); }

Объект команды очень прост, по крайней мере в нашем случае. Он содержит лишь

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

модели, помещает в запрос информацию, необходимую для отображения результатов, и

передает управление представлению по шаблону (Template View, 368).

class ArtistCorranand...

public void process() throws ServletException, IOException {

Artist artist = Artist.findNamed(request.getParameter(

"name"));

request.setAttribute("helper", new ArtistHelper(artist));

forward("/artist.j sp") ; }

И наконец, класс unknownCommand выводит на экран страницу с банальным сообще-

нием об ошибке.

class UnknownCommand...

public void process () throws ServletException, IOException {

forward("/unknown.j sp");

}

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

Представление по шаблону (Template View)

Преобразует результаты выполнения запроса в формат HTML

путем внедрения маркеров в HTML-страницу

Написать программу, генерирующую код HTML, гораздо сложнее, чем может пока-

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

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

ку символов в старом добром ФОРТРАНе или стандартной версии Pascal), создание и

конкатенация строковых конструкций все еще связаны с массой неудобств. Данная про-

блема не так страшна, если текста не слишком много, однако создание целой HTML-

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

Для редактирования статических HTML-страниц (тех, содержимое которых не изме-

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

работающие по принципу WYSIWYG (What You See Is What You Get — что видишь на эк-

ране, то и получишь при печати). Даже тем, кто предпочитает самые примитивные редак-

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

строк в коде программы.

Основные трудности связаны с созданием динамических Web-страниц — тех, которые

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

и внедряют их в код HTML. Содержимое такой страницы меняется с каждым запросом,

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

Наиболее удобный способ создания динамической Web-страницы — конструирова-

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

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

информацию. Поскольку статическая часть страницы выступает в роли своеобразного

шаблона, я называю это типовое решение представлением по шаблону.

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

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

Основная идея, лежащая в основе типового решения представление по шаблону, —

вставка маркеров в текст готовой статической HTML-страницы. При вызове страницы

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

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

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

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

языков программирования. Для получения динамической информации маркеры об-

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

Представление по шаблону используется целым рядом программных средств. Таким

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

мому, сколько в том, чтобы научиться его эффективно использовать и познакомиться

с возможными альтернативами.

Вставка маркеров

Существует несколько способов внедрения маркеров в HTML-страницу. Один из

них — это использование HTML-подобных дескрипторов. Данный способ хорошо под-

ходит для редакторов, работающих по принципу WYSIWYG, поскольку они распознают

элементы, заключенные в угловые скобки (<>), как специальное содержимое и поэтому

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

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

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

рующий документ HTML является документом XHTML).

Еще один способ внедрения динамического содержимого— вставка специальных

текстовых маркеров в тело страницы. В этом случае текстовые редакторы WYSIWYG бу-

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

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

ливым операциям, например проверке орфографии. Тем не менее данный способ позво-

ляет обойтись без запутанного синтаксиса HTML/XML.

Некоторые среды разработки содержат наборы готовых маркеров, однако все боль-

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

и маркеры в соответствии с нуждами конкретных приложений.

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

сервера (serverpage) — ASP, JSP или PHP. Вообще говоря, страницы сервера — это нечто

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

элементы программной логики, называемые скриптлетами (scriptlets). Я, однако, рас-

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

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

шаблону.

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

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

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

ские дизайнеры. Однако самые существенные недостатки скриптлетов связаны с тем,

что страница — далеко не самый подходящий модуль для программы. Даже при ис-

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

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

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

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

дурном стиле.

Однако гораздо неприятнее то, что внедрение в страницу большого числа скриптлетов

приводит к "перемешиванию" слоев корпоративного приложения. Если логика домена

запускается прямо на страницах сервера, она практически не поддается структурирова-

нию и вместе с тем может легко привести к дублированию логики на других страницах

сервера. Что ни говори, а самым кошмарным кодом, который мне довелось увидеть за

последние несколько лет, был код страницы сервера.

Вспомогательный объект

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

ственный вспомогательный объект (helper object). Этот объект будет содержать в себе всю

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

та, что значительно упростит структуру страницы и максимально приблизит ее к "чис-

той" форме представления по шаблону. Более того, это обеспечит возможность "разде-

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

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

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

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

страницы и сделает ее более пригодной для поддержки стандартными средствами.

Описанная схема кажется простой и вполне заслуживающей доверия. Тем не менее,

как всегда, здесь есть несколько но. Самые простые маркеры — это те, которые полу-

чают информацию из остальной части системы и помещают эту информацию в нужное

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

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

то, что может быть легко преобразовано в текст). Этот текст и помещается в указанное

место страницы.

Условное отображение

Гораздо сложнее реализовать условное поведение страницы. Самый простой пример

условного поведения — это когда результат выполнения запроса отображается только в

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

может быть реализовано с помощью условных дескрипторов наподобие <IF condition

= "$падение_цены > 0.1"> . . . отобразить__что_нибудь </IF>. К сожалению, ИС-

пользование условных дескрипторов постепенно превращает шаблонные страницы в не-

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

зование скриптлетов. Если вам нужен полноценный язык программирования, вы можете

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

этой идее!

Из всего сказанного выше можно понять, что я не приветствую использование услов-

ных дескрипторов и рекомендую всячески их избегать. Разумеется, это не всегда возмож-

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

конкретного приложения, чем универсальный дескриптор <IF>.

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

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

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

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

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

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

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

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

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

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

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

блемы — генерация разметки вспомогательным объектом. Это позволит очистить

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

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

низм выделения текста.

Чтобы управление HTML-разметкой осталось в руках дизайнера страниц, необходи-

мо воспользоваться условными дескрипторами. В такой ситуации очень важно не опус-

титься до применения простого дескриптора <IF>. Удачным решением является приме-

нение дескрипторов, направленных на выполнение определенных действий. Например,

вместо дескриптора

можно применить дескриптор

</highlight>

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

нове единственного булева свойства вспомогательного объекта. Наличие на странице бо-

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

Еще одним примером условного поведения является отображение той или иной ин-

формации в зависимости от используемого в системе регионального стандарта. Предпо-

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

США или Канады. В этом случае вместо универсального дескриптора

<IF expression = "locale = 'US' || 'CA'"> ...special text </IF>

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

<locale includes = "US, CA"> ...special

text </locale>

Итерация

Похожие проблемы связаны с итерацией по коллекциям объектов. Если вы хотите

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

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

строке. В данном примере практически невозможно избежать итерации по дескриптору

коллекций, однако обычно она выполняется довольно легко.

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

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

разработки. Некоторые среды разработки предоставляют фиксированный набор деск-

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

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

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

теки дескрипторов.

Обработка страницы

Как следует из названия, главной функцией типового решения представление по шаб-

лону является выполнение роли представления в системе модель—представление-

контроллер (Model View Controller, 347). В большинстве корпоративных систем представ-

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

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

я настоятельно рекомендую максимально отделять модель от представления. Если

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

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

печивал вспомогательный объект, а не страница сервера. Выполнение обязанностей кон-

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

другая программная логика, должна находиться во вспомогательном объекте.

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

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

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

интерпретации страницы при поступлении каждого запроса. Последний вариант, оче-

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

время.

Работая с представлением по шаблону, следует обращать внимание на исключения. Ес-

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

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

Понаблюдайте, как Web-сервер обрабатывает исключения. Если он делает что-то не то,

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

классе (еще одна причина, по которой следует избегать скриптлетов).

Использование сценариев

Хотя наиболее популярной формой представления по шаблону были и остаются стра-

ницы сервера, в случае необходимости их можно заменить сценариями. Я уже встречал

сценарии Perl, написанные по типу представления по шаблону. Главное при написании

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

будут возвращать необходимые дескрипторы (это особенно хорошо демонстрируют сце-

нарии CGI). Данный прием позволит создавать сценарий на привычном языке програм-

мирования, избегая досадных "вкраплений" в программную логику в виде функций вы-

вода строк на экран.

Назначение

Основными альтернативами для реализации представления в системе модель-

представление—контроллер являются представление по шаблону и представление с преоб-

разованием (Transform View, 379). Преимущество представления по шаблону состоит в том,

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

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

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

В частности, она позволяет воплотить в жизнь идею, когда графический дизайнер за-

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

объектом.

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

представление в виде страницы сервера, последнюю весьма легко переполнить логикой.

Это значительно усложнит ее дальнейшую поддержку, особенно для людей, не являю-

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

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

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

тестировать, чем представление с преобразованием. Большинство реализаций представле-

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

их невозможно или практически невозможно протестировать в другом контексте. Реа-

лизации представления с преобразованием значительно легче поддаются тестированию

и могут функционировать и при отсутствии запущенного Web-сервера.

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

(Two Step View, 383). В зависимости от используемой схемы шаблона, это типовое реше-

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

лизация двухэтапного представления на основе представления с преобразованием может

оказаться значительно легче. Не забывайте об этом!

Пример: использование страницы JSP в качестве представления с

вынесением контроллера в отдельный объект (Java)

Если страница JSP применяется исключительно в качестве представления, она всегда

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

образом, странице JSP нужно передать всю информацию, необходимую для отображения

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

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

вался в примере простого отображения для контроллера страниц (Page Controller, 350).

Метод обработки запроса сервлетом выглядит как показано ниже.

class ArtistController...

public void doGet(HttpServletRequest request,

^HttpServletResponse response)

throws IOException, ServletException { Artist artist =

Artist.findNamed(request.getParameter(

V'name"));

if (artist == null)

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

else {

request.setAttribute ( "helper", new ArtistHelper(

"^artist) ) ;

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