Фаулер М. Архитектура корпоративных программных приложений
Подождите немного. Документ загружается.
394 Часть II. Типовые решения
Каждый дескриптор второго этапа имеет реализацию, которая генерирует код HTML
для соответствующего элемента логического экрана. Самый простой из пользователь-
ских дескрипторов — <title> ("название").
class TitleTag...
public int doStartTag () throws JspException {
try {
pageContext.getOut().print("<H1>"); }
catch (IOException e) {
throw new JspException("unable to print start");
}
return EVAL_BODY_INCLUDE; }
public int doEndTagO throws JspException { try
{
pageContext.getOut().print("</Hl>");
} catch (IOException e) (
throw new JspException("unable to print end"); }
return EVAL_PAGE;
}
Для тех, кто еще не знает, поясню: класс пользовательского дескриптора реализует
методы, которые вызываются в начале и в конце текста, заключенного в соответствую-
щий дескриптор. В данном примере класс TitleTag просто заключает содержимое деск-
риптора <titie> в HTML-дескриптор <HI>. Более сложный дескриптор, такой, как
<f ield>, может содержать атрибут. Этот атрибут передается классу дескриптора с по-
мощью set-метода.
class FieldTag...
private String label;
public void setLabel(String label) {
this.label = label; }
После установки значения атрибута его можно использовать в качестве параметра
преобразования второго этапа.
class FieldTag...
public int doStartTag() throws JspException {
try {
pageContext.getOut () .print("<P>" + label + ": <B>");
} catch (IOException e) {
throw new JspException("unable to print start");
}
return EVAL_BODY_INCLUDE; } public int
doEndTagO throws JspException {
try {
Глава 14. Типовые решения, предназначенные для представления данных в Web 395
pageContext. getOut () .print ("</BX/P>") ;
} catch (IOException e) {
throw new JspException("how are checked exceptions helping
me here?"); }
return EVAL_PAGE;
}
Самым сложным из дескрипторов второго этапа является <tabie>. Помимо выбо-
ра нужных столбцов, он описывает выделение разными цветами чередующихся строк
таблицы. Реализация этого дескриптора применяется на втором этапе преобразования,
поэтому выделение цветом будет относиться ко всем таблицам сайта (при наличии та-
ковых).
Класс TableTag имеет закрытые поля collectionName (имя коллекции свойств),
hostName (имя объекта, хранящего в себе коллекцию свойств) и columns (список разде-
ленных запятыми имен столбцов).
class TableTag...
private String collectionName;
private String hostName;
private String columns;
public void setCollection(String collectionName) {
this.collectionName = collectionName; }
public void setHost(String hostName) {
this.hostName = hostName; } public void
setColumns(String columns) {
this.columns = columns;
}
Я создал вспомогательный метод для извлечения из объекта значения нужного свой-
ства. Вообще говоря, в подобных случаях рекомендуется применять различные классы,
поддерживающие компоненты Java Beans, а не просто вызывать методы типа
"get что_то", однакодля нашего примера подойдет и последнее.
class TableTag...
private Object getProperty(Object obj, String property)
throws JspException { try {
String methodName = "get" + property.substring( 0,
1) .toUpperCase () + property.substring (1);
Object result = obj.getClass () .getMethod(methodName,
null).invoke(obj, null);
return result; }
catch (Exception e) {
throw new JspException("Unable to get property " +
property + " from " + obj);
}
)
396 Часть II. Типовые решения
Дескриптор <table> не имеет тела. При вызове метода doStartTag последний из-
влекает коллекцию с заданным именем из указанного свойства объекта запроса и после-
довательно перебирает объекты этой коллекции для генерации строк таблицы.
class TableTag...
public int doStartTag() throws JspException {
try {
JspWriter out = pageContext.getOut();
out.print("<table>"); Collection coll =
(Collection)
getPropertyFromAttribute(hostName, collectionName);
Iterator rows = coll.iterator(); int rowNumber
= 0; while (rows.hasNext()) { out.print("<tr");
if ((rowNumber++ % 2) == 0) out.print ( " bgcolor =
" + HIGHLIGHT_COLOR) ; out.print(">");
printCells(rows.next()); out.print("</tr>"); }
out.print("</table>"); }
catch (IOException e) {
throw new JspException("unable to print out");
}
return SKIP_BODY;
}
private Object getPropertyFromAttribute(String attribute,
String property)
throws JspException
{
Object hostObject = pageContext.findAttribute(attribute);
if (hostObject == null)
throw new JspException("Attribute " + attribute + "
not found.");
return getProperty(hostObject, property); } public
static final String HIGHLIGHT_COLOR = "'linen'";
В процессе итерации каждая четная строка таблицы выделяется бежевым цветом. Чтобы
напечатать содержимое ячеек каждой строки, я использую имена столбцов для
извлечения значений соответствующих свойств объектов коллекции.
class TableTag...
private void printCells(Object obj) throws IOException,
JspException {
JspWriter out = pageContext.getOut(); for (int i =
0; i < getColumnList().length; i++) {
out.print("<td>");
out.print(getProperty(obj, getColumnList()[i]));
out.print("</td>");
Глава 14. Типовые решения, предназначенные для представления данных в Web 397
private String[] getColumnList() {
StringTokenizer tk = new StringTokenizer(columns, ", ");
String[] result = new String[tk.countTokens()];
for (int i = 0; tk.hasMoreTokens(); i++)
result[i] = tk.nextToken();
return result;
}
По сравнению с реализацией на языке XSLT данное решение накладывает меньше ог-
раничений на структуру страниц. Например, автору отдельной страницы будет легче раз-
местить на ней какой-нибудь "свой" элемент, которого нет на других страницах сайта.
Эта возможность имеет и недостатки: допускает появление ненужных элементов оформ-
ления или случайных ошибок, сделанных людьми, которые плохо знакомы с данной схе-
мой преобразования. Иногда ограничения действительно помогают избежать неприятно-
стей. Команда разработчиков должна сама принять решение о том, какие преимущества
для нее важнее.
Контроллер приложения (Application Controller)
Точка централизованного управления порядком отображения
интерфейсных экранов и потоком функции приложения
Некоторые приложения содержат огромное количество логики, касающейся порядка
отображения интерфейсных экранов: например, какой экран следует отобразить на той
или иной стадии приложения. Подобное взаимодействие приложения с пользователем
аналогично работе программ-мастеров, которые последовательно проводят пользователя
398 Часть II. Типовые решения
по набору диалоговых окон, расположенных в строго заданном порядке. В качестве дру-
гих примеров можно привести диалоговые окна, которые отображаются только при оп-
ределенных условиях, или же выбор нужного окна в зависимости от данных, введенных
пользователем на предыдущей стадии.
В некоторой степени выполнение подобных функций обеспечивают входные кон-
троллеры из системы модель—представление—контроллер (Model View Controller, 347).
Тем не менее по мере повышения сложности приложения логика выбора нужных экра-
нов начинает дублироваться в нескольких контроллерах, что весьма нежелательно.
Во избежание подобного дублирования всю логику, касающуюся управления потоком
функций приложения, можно поместить в контроллер приложения. В этом случае вход-
ные контроллеры будут обращаться к контроллеру приложения за командами, которые
следует применить к модели, и за представлениями, которые необходимо использовать
в определенном контексте приложения.
Принцип действия
Контроллер приложения выполняет две основные функции: выбор логики домена, ко-
торую нужно применить в конкретной ситуации, и выбор представления, которое следует
отобразить в ответ на запрос. Для осуществления этих функций контроллер приложения
поддерживает две коллекции ссылок на классы — одну для команд, выполняющихся
в слое домена, и одну для представлений (рис. 14.10).
Рис. 14.10. Контроллер приложения содержит две коллекции ссылок на классы: для логики
домена и для представлений
И в том и в другом случае контроллеру приложения необходим способ обращения
к командам или представлениям. Удачным выбором является типовое решение команда
(Command) [20], поскольку оно позволяет легко управлять выполнением фрагментов
кода. При использовании языков, поддерживающих операции над функциями, контрол-
лер приложения может содержать ссылки на объекты команд. Еще одной возможностью
является хранение строки, которая может быть использована для вызова нужного метода
посредством отражения.
В качестве команд домена могут выступать объекты команд, являющиеся частью слоя
контроллера приложения, либо ссылки на сценарий транзакции (Transaction Script, 133)
или методы объектов домена.
Глава 14. Типовые решения, предназначенные для представления данных в Web 399
Если в качестве представлений используются страницы сервера, для вызова представ-
ления можно применить имя соответствующей страницы. Если же представление являет-
ся классом, стоит подумать о хранении команды или строки для применения метода
отражения. И наконец, представление может быть таблицей стилей XSLT, ссылка на ко-
торую в виде строки будет храниться в контроллере приложения.
Разрабатывая контроллер приложения, необходимо подумать о том, насколько он дол-
жен быть отделен от остальной части слоя представления. При этом необходимо учесть,
зависит ли от контроллера приложения аппарат пользовательского интерфейса. Возмож-
но, контроллер напрямую осуществляет доступ к данным из HTTP-сеанса, передает
управление странице сервера или вызывает методы класса толстого клиента.
Что касается меня, то я отдаю предпочтение контроллерам приложения, не связанным
с аппаратом пользовательского интерфейса. Прежде всего это позволяет тестировать кон-
троллер приложения независимо от пользовательского интерфейса, что уже само по себе
очень удобно. Кроме того, это дает возможность использовать один и тот же контроллер
приложения с несколькими интерфейсами. В связи с этим многие разработчики рассмат-
ривают контроллер приложения как промежуточный слой между представлением и пред-
метной областью.
Приложение может иметь несколько контроллеров приложения, управляющих его
составными частями. Благодаря этому сложная логика выбора интерфейсных экранов
может быть распределена по нескольким классам. В подобных случаях я рекомендую
создавать отдельный контроллер приложения на каждую область пользовательского ин-
терфейса. Более простому приложению достаточно и одного контроллера.
Если у приложения есть несколько представлений, например Web-интерфейс, тол-
стый клиент и интерфейс для отображения на карманном компьютере, можете приме-
нить к каждому из них один и тот же контроллер приложения, но не перестарайтесь. За-
частую для получения действительно удобных интерфейсов каждому из них нужен свой
порядок отображения экранов. Впрочем, повторное использование одного и того же кон-
троллера приложения способно настолько сократить объем работы, что может вполне оп-
равдать не слишком удобный пользовательский интерфейс.
Очень часто механизм пользовательского интерфейса рассматривают как модель со-
стояний, в котором конкретные события могут инициировать различные отклики, в за-
висимости от состояния определенных объектов приложения. В этом случае для пред-
ставления управляющей логики модели состояний удобно использовать метаданные.
Эти метаданные могут задаваться средствами языка программирования (самый простой
способ) или же храниться в отдельном файле настроек.
Иногда в контроллер приложения помещают логику домена, относящуюся к обработке
конкретного запроса. Вообще говоря, я не приветствую подобные решения. Тем не менее
следует признать, что граница между логикой приложения и логикой домена не всегда
поддается точному определению. Предположим, я обрабатываю заявления о медицин-
ском страховании и должен отобразить дополнительное окно с набором вопросов только
в том случае, если заявитель — курильщик. Что это — логика приложения или логика до-
мена? Если таких случаев не слишком много, я могу вынести эту логику в контроллер
приложения, однако если подобные ситуации возникают по ходу всего приложения, при-
дется реализовать их обработку в модели предметной области (Domain Model, 140).
400 Часть II. Типовые решения
Назначение
Если логика Web-приложения, описывающая порядок отображения интерфейсных
экранов, довольно проста (другими словами, если пользователь может открывать экраны
приложения практически в любом порядке), применять контроллер приложения не имеет
смысла. Основное преимущество данного типового решения состоит именно в определе-
нии порядка отображения страниц и выборе тех или иных представлений в зависимости
от состояний объектов.
Необходимость использования контроллера приложения очевидна, если различные
изменения хода приложения требуют применения схожей логики, касающейся выбора
команд или представлений, особенно если такие изменения возникают во многих местах
приложения.
Дополнительные источники информации
Большинство идей, лежащих в основе данного типового решения, были взяты из ста-
тьи [25]. Хотя подобные идеи выдвигались и раньше, объяснения, предложенные авто-
рами этой статьи, показались мне наиболее четкими и логичными.
Пример: модель состояний контроллера приложения (Java)
Механизм пользовательского интерфейса нередко рассматривают как модель состоя-
ний. Подобная формализация особенно верна, когда приложение должно по-разному
реагировать на события в зависимости от состояний некоторых объектов. В этом приме-
ре я использую простую модель состояний для описания нескольких операций, выпол-
няемых над имуществом (рис. 14.11). Эксперты по лизингу компании ThoughtWork были
бы повергнуты в шок таким вопиющим упрощением дел, однако в качестве примера кон-
троллера приложения, основанного на использовании состояний, моя модель не так уж и
плоха.
Рис. 14.11. Простая модель состояний имущества
Глава 14. Типовые решения, предназначенные для представления данных в Web 401
Выполнение переходов в рассматриваемой модели состояний описывается тремя пра-
вилами.
• Если при получении команды return ("возврат") имущество находится в состоя
нии ON_LEASE ("сдано в аренду"), приложение отображает страницу для ввода
данных о возврате имущества.
• Вызов команды return в состоянии IN_INVENTORY ("на складе") является недо
пустимым действием. В этом случае приложение отображает страницу с сообще
нием о попытке выполнения недопустимого действия.
• При получении команды damage ("повреждение") приложение отображает разные
страницы, в зависимости от того, в каком состоянии находится имущество —
ON_LEASE ИЛИ IN_INVENTORY.
В качестве входного контроллера будет применяться контроллер запросов (Front
Controller, 362), который выполняет обслуживание запросов.
class FrontServlet...
public void service(HttpServletRequest request,
^HttpServletResponse response)
throws IOException, ServletException
{
ApplicationController appController =
4>getApplicationController(request);
String commandString = (String) request.getParameter(
V'command");
DomainCommand corara = appController.getDomainCommand(
^commandString, getParameterMap(request) ) ;
comm.run(getParameterMap(request) ) ;
String viewPage = "/" + appController.getView(
4>commandString, getParameterMap(request)) + ".jsp";
forward(viewPage, request, response);
}
Логика метода service крайне проста: определяем контроллер приложения, соответ-
ствующий заданному запросу; спрашиваем у контроллера, какую команду домена следует
применить; выполняем указанную команду; спрашиваем у контроллера, какое представ-
ление следует отобразить; передаем управление указанному представлению.
Данная схема предполагает наличие нескольких контроллеров приложения, реали-
зующих общий интерфейс.
interface ApplicationController...
DomainCommand getDomainCommand (String commandString,
4>Map pa rams) ;
String getView (String commandString, Map params);
В нашем примере контроллер приложения будет реализован в виде класса AssetAp-
plicationcontroller. Для хранения ссылок на команды домена и представления
402 Часть II. Типовые решения
контроллер приложения будет использовать класс Response. При этом обращение к ко-
мандам домена будет осуществляться посредством ссылки на класс команды, а обраще-
ние к представлениям — с помощью строки, которая будет преобразована контроллером
запросов в адрес URL, соответствующий странице JSP.
class Response.. .
private Class domainCommand;
private String viewUrl;
public Response(Class domainCommand, String viewUrl) {
this.domainCommand = domainCommand;
this.viewUrl = viewUrl; } public
DomainCommand getDomainCommand() {
try {
return (DomainCommand) domainCommand.newlnstance ();
} catch (Exception e) {throw new ApplicationException (e);
} } public String
getViewUrl() {
return viewUrl; }
Контроллер приложения управляет выбором откликов, используя коллекцию кол-
лекций, индексированных по имени команды и состоянию имущества (рис. 14.12).
class AssetApplicationController...
private Response getResponse(String commandString,
AssetStatus state) {
return (Response) getResponseMap(commandString).get(
state); } private Map getResponseMap (String key) {
return (Map) events.get(key); }
private Map events = new HashMapO;
Когда контроллер приложения получает запрос на выбор необходимой команды,
он просматривает запрос, чтобы определить идентификатор предмета имущества,
обращается к домену, чтобы выяснить состояние этого предмета имущества, находит
соответствующий класс команды домена, создает экземпляр этого класса и возвращает
созданный объект.
class AssetApplicationController...
public DomainCommand getDomainCommand (String commandString,
Map params) {
Response reponse = getResponse(commandString,
getAssetStatus(params));
return reponse.getDomainCommand();
}
Глава 14. Типовые решения, предназначенные для представления данных в Web 403
private AssetStatus getAssetStatus(Map params) {
String id = getParam("assetID", params);
Asset asset = Asset.find(id);
return asset.getStatus();
}
private String
getParam(String key, Map params) {
return ((String!]) params.get(key))[0];
Рис. 14.12. Схема хранения контроллером приложения ссылок на команды домена и представления
Все классы команд домена реализуют простой интерфейс, который позволяет исполь-
зовать их в модели контроллера запросов.
interface DomainCommand...
abstract public void run(Map params);
После выполнения указанной команды контроллер запросов снова обращается к кон-
троллеру приложения, на сей раз с просьбой определить необходимое представление.