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

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

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

хранилища позволяет применить ту или иную стратегию выполнения запроса в зависимо-

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

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

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

удаленным сервером, например поток данных XML, поступающий из Internet (возможно,

посредством протокола SOAP). В этом случае можно реализовать стратегию XmlFeedRe-

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

в объекты домена.

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

Типовое решение спецификация еше не фигурирует в какой-либо серьезной справоч-

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

вому решению остается [14]. Более удачное описание будет приведено в [15], однако на

данный момент эта книга еще находится в стадии подготовки.

Пример: поиск подчиненных заданного сотрудника (Java)

С точки зрения клиента, использование хранилища не представляет собой ничего

сложного. Чтобы извлечь из базы данных список подчиненных соответствующего со-

трудника, объект Person создает объект Criteria, содержащий описание критерия по-

иска, и отсылает его нужному хранилищу.

public class Person {

public List dependents() {

Repository repository = Registry.personRepository();

Criteria criteria = new Criteria();

criteria.equal(Person.BENEFACTOR, this); return

repository.matching(criteria); } }

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

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

PersonRepository, производный от Repository, и переместить создание критерия по-

иска в новый класс.

public class PersonRepository extends Repository {

public List dependentsOf(Person aPerson) { Criteria

criteria = new Criteria();

criteria.equal(Person.BENEFACTOR, aPerson); return

matching(criteria); } }

Глава 13. Типовые решения объектно-реляционного отображения... 345

После этого объект Person сможет вызвать метод dependentsOf () прямо из своего

хранилища PersonRepository.

public class Person {

public List dependents() {

return Registry.personRepository().dependentsOf(this);

} }

Пример: выбор стратегий хранилища (Java)

Поскольку интерфейс хранилища надежно скрывает источник данных от слоя домена,

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

поступающих от клиентов. Действительно, код домена не должен "беспокоиться" об ис-

точнике или назначении объектов домена. Когда источник данных расположен в опера-

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

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

ному критерию. При этом не предполагается изменять источник данных "навсегда"; ско-

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

когда это потребуется. Отсюда следует необходимость изменить метод matching () так,

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

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

каждую из них для обработки конкретной ситуации. В нашем случае целесообразно соз-

дать два объекта стратегии: объект Relationalstrategy, который будет выполнять за-

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

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

фейс Repositorystrategy, который предоставляет доступ к методу matching (), по-

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

abstract class Repository {

private Repositorystrategy strategy;

protected List matching(Criteria aCriteria) {

return strategy.matching(aCriteria);

} }

Класс Relationalstrategy реализует метод matching () путем создания

объекта

запроса на основе заданного критерия и использования этого объекта для запроса к базе

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

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

метод для добавления критериев.

public class Relationalstrategy implements Repositorystrategy {

protected List matching(Criteria criteria) {

Query query = new Query(myDomainObjectClass())

query.addCriteria(criteria); return

query.execute(unitOfWork());

Глава 14

Типовые решения,

предназначенные

для представления

данных в Web

Модель—представление—контроллер (Model View Controller)

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

интерфейсом между тремя участниками

Типовое решение модель—представление—контроллер — одно из наиболее часто цити-

руемых (и, к сожалению, неверно истолковываемых). Первоначально оно появилось в

виде инфраструктуры, разработанной Тригве Реенскаугом (Trigve Reenskaug) для плат-

формы Smalltalk в конце 70-х годов прошлого столетия. С тех пор оно сыграло значи-

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

цепций проектирования пользовательского интерфейса.

348 Часть !! Типовые решения

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

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

отдельных ролей. Модель— это объект, предоставляющий некоторую информацию о

домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведе-

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

тексте наиболее "чистой" формой модели является объект модели предметной области

(Domain Model, 140). В качестве модели можно рассматривать и сценарий транзакции

(Transaction Script, 133), если он не содержит в себе никакой логики, связанной с пользо-

вательским интерфейсом. Подобное определение не очень расширяет понятие модели,

однако полностью соответствует распределению ролей в рассматриваемом типовом ре-

шении.

Представление отображает содержимое модели средствами графического интерфейса.

Таким образом, если наша модель — это объект покупателя, соответствующее представ-

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

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

бражении информации на экране. Все изменения информации обрабатываются третьим

"участником" нашей системы — контроллером. Контроллер получает входные данные от

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

димость соответствующего обновления. В этом плане графический интерфейс можно

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

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

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

контроллера от представления.

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

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

по ряду причин.

• Представление и модель относятся к совершенно разным сферам программирова

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

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

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

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

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

разные!) библиотеки. Кроме того, большинство разработчиков специализируются

только в одной из этих областей.

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

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

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

а точнее, несколько абсолютно разных интерфейсов. Наиболее наглядно данный

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

лена с помощью толстого клиента, Web-обозревателя, удаленного API или интер

фейса командной строки. Даже в пределах одного и того же Web-интерфейса в

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

разные страницы.

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

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

объекты с интерфейсом. Отделение представления от модели позволяет легко про-

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

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

Ключевым моментом в отделении представления от модели является направление

зависимостей: представление зависит от модели, но модель не зависит от представления.

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

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

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

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

Данный принцип тесно связан с распространенной проблемой. При использовании

толстого клиента с множеством диалоговых окон на экране могут одновременно нахо-

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

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

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

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

(Observer) [20] с использованием метода распространения событий (event propagation)

или в виде типового решения слушатель (Listener). В этом случае представление будет

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

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

свое содержимое.

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

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

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

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

редактируемого поведения. Этого можно достичь при наличии одного представления и

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

тегиями [20], используемыми представлением. Между тем на практике в большинстве

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

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

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

полезным.

Тот факт, что в большинстве инфраструктур пользовательских интерфейсов не про-

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

кований типового решения модель-представление—контроллер. Да, наличие модели и

представления очевидно, но где же контроллер? Многие решили, что контроллер нахо-

дится между моделью и представлением, как в контроллере приложения (Application

Controller, 397). Данное заблуждение еще более усугубил тот факт, что в обоих названиях

фигурирует слово "контроллер". Между тем, несмотря на все положительные качества

контроллера приложения, он ничем не похож на контроллер типового решения модель-

представление—контроллер.

Описанные принципы — это все, что требуется для понимания данного набора типо-

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

дель-представление—контроллер, обратитесь к источнику [33] — там содержится лучшее

на данный момент описание этого типового решения.

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

Назначение

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

заключается в наличии двух типов разделения. Отделение представления от модели —

один из основополагающих принципов, на котором держится все проектирование про-

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

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

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

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

интерфейсов реализовать подобное разделение довольно сложно, а там, где это неслож-

но, о нем все равно забывают.

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

дить его только в том случае, когда оно действительно нужно. Подобная необходимость

практически не возникает в системах с толстыми клиентами, а вот в Web-интерфейсах

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

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

этом принципе.

Контроллер страниц (Page Controller)

Объект, который обрабатывает запрос к конкретной Web-странице

или выполнение конкретного действия на Web-сайте

Большинство пользователей Internet когда-либо сталкивались со статическими

HTML-страницами. Когда посетитель сайта запрашивает статическую страницу, он пе-

редает Web-серверу имя и путь к HTML-документу, который хранится на этом сервере.

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

сервере отдельным документом. С динамическими страницами дело обстоит далеко не

так просто из-за более сложных отношений между именами путей и соответствующими

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

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

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

Типовое решение контроллер страниц предполагает наличие отдельного контроллера

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

ница (как часто бывает в окружениях страниц сервера) или отдельный объект, соответст-

вующий данной странице.

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

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

полнять роль контроллеров для каждой страницы Web-сайта. На практике количество

контроллеров не всегда в точности соответствует количеству страниц, поскольку иногда

при щелчке на ссылке открываются страницы с разным динамическим содержимым. Ес-

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

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

Контроллер страниц может быть реализован в виде сценария (сценария CGI, сервлета

и т.п.) или страницы сервера (ASP, PHP, JSP и т.п.). Использование страницы сервера

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

шаблону (Template View, 368). Это хорошо для представления по шаблону, но не очень под-

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

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

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

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

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

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

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

том (helper object). При получении запроса страница сервера вызывает вспомогательный

объект для обработки всей имеющейся логики. В зависимости от ситуации, вспомога-

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

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

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

логики контроллера заключена во вспомогательном объекте.

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

контроллера в виде сценария. В этом случае при поступлении запроса Web-сервер пере-

дает управление сценарию; сценарий выполняет все действия, возложенные на контрол-

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

Ниже перечислены основные обязанности контроллера страниц.

• Проанализировать адрес URL и извлечь данные, введенные пользователем в соот

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

действия.

• Создать объекты модели и вызвать их методы, необходимые для обработки дан

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

ее объекты были полностью независимы от этого запроса.

• Определить представление, которое должно быть использовано для отображения

результатов, и передать ему необходимую информацию, полученную от модели.

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

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

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

Это особенно удобно, если на Web-сервере должно быть несколько обработчиков, вы-

полняющих аналогичные задания. В этом случае использование вспомогательного объ-

екта позволяет избежать дублирования кода.

При необходимости одни адреса URL можно обрабатывать с помощью страниц

сервера, а другие — с помощью сценариев. Те адреса URL, у которых нет или почти нет

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

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

изменений. Все остальные адреса, для обработки которых необходима более сложная

логика, требуют применения сценариев. Я встречал приложения, в которых все страницы

обрабатывались одним и тем же способом: либо с применением страниц сервера, либо с

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

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

сценариями, либо на фоне огромного множества простых сценариев.

Назначение

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

троллер следует использовать— контроллер страниц или контроллер запросов (Front

Controller, 362). Контроллер страниц более прост в работе и представляет собой естест-

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

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

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

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

Контроллер страниц хорошо применять для сайтов с достаточно простой логикой кон-

троллера. В этом случае большинство адресов URL могут обрабатываться с помощью

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

Если логика контроллера довольно проста, использование контроллера запросов приведет

к ненужным расходам.

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

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

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

тельности эти типовые решения хорошо сочетаются между собой.

Пример: простое отображение с помощью контроллера-сервлета

и представления JSP (Java)

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

что-нибудь отображать, например сведения об исполнителе (рис. 14.1). Адрес URL на-

шей страницы будет ВЫГЛЯДеть как http: //www.thingy.com/recordingApp/artist?

name=danielaMercury.

Рис. 14.1. Классы, принимающие участие в отображении данных вместе с контроллером страниц,

реализованным в виде сервлета, и представлением JSP

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

/artist как обращение к объекту Artistcontroller. В контейнере сервлетов Tomcat

это делается путем добавления в файл web. xml приведенного далее кода.

<servlet-name>artist</servlet-name>

<servlet-class>actionController.ArtistController

^4></servlet-class> </servlet> <servlet-mapping>

<servlet-name>artist</servlet-name>

<url-pattern>/artist</url-pattern>

</servlet-mapping>

Класс Artistcontroller должен реализовать метод для обработки запроса.

class Artistcontroller...

public void doGet(HttpServletRequest request,

4>HttpServletResponse response)

throws IOException, ServletException { Artist

artist = Artist.findNamed( 4j> request.

getParameter ("name")); if (artist == null)

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

else {

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