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

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

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

public void testArtist() {

assertEquals(kob.getArtist(), newkob.getArtist()); }

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

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

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

Пример: Web-служба (С#)

Однажды я разговаривал с Майком Хендриксоном (Mike Hendrickson), редактором

издательства Addison-Wesley, работавшим над этой книгой. Майк, которого страшно

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

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

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

ней "модный" материал окажется неактуальным. Тем не менее я все-таки решил кос-

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

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

По своей сути Web-служба — это не более чем интерфейс удаленного доступа (снаб-

женный для солидности достаточно медленным этапом синтаксического анализа).

Реализация Web-служб соответствует основному принципу построения интерфейса

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

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

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

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

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

рис. 15.3. Это уже знакомые нам группы классов: класс AlbumService, выполняющий

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

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

области в объект переноса данных.

Рассматриваемая модель предметной области до смешного проста. Вообще говоря, в

подобном примере было бы проще воспользоваться шлюзом таблицы данных (Table Data

Gateway, 167), чтобы напрямую создавать объекты переноса данных. Однако это бы ис-

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

области.

class Album...

public String Title;

public Artist Artist;

public IList Tracks {

get {return ArrayList.Readonly(tracksData) ;}

}

public void AddTrack (Track arg) {

tracksData.Add(arg);

}

public void RemoveTrack (Track arg) {

tracksData.Remove(arg); } private IList

tracksData = new ArrayList();

Глава 15. Типовые решения распределенной обработки данных 415

class Artist. . .

public String Name;

class Track.. .

public String Title; public

IList Performers {

get {return ArrayList.Readonly(performersData);}

} public void AddPerformer (Artist arg) {

performersData.Add(arg); } public void

RemovePerformer (Artist arg) {

performersData.Remove(arg) ; } private IList

performersData = new ArrayList();

Рис. 15.3. K/iaccbi, принимающие участие в работе Web-службы AlbumServke

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

Для передачи данных по сети я воспользовался объектами переноса данных. Они пред-

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

удобства использования их Web-службой.

class AlbumDTO...

public String Title; public

String Artist; public

TrackDTO[] Tracks;

class TrackDTO...

public String Title; public

String!] Performers;

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

данных в XML. В состав инфраструктуры .NET входит специальный класс, который са-

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

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

коде WSDL. Что приятно, средства Visual Studio позволяют автоматически сгенерировать

код WSDL (а я, как известно, очень ленив). Ниже приведено определение схемы XML,

соответствующее объекту переноса данных.

<s:complexType name="AlbumDTO">

<s:sequence>

<s:element minOccurs="l" maxOccurs="l" name="Title"

4>nillable="true" type="s:string" />

<s:element minOccurs="l" maxOccurs="l" name="Artist"

^nillable="true" type="s:string" />

<s:element minOccurs="l" maxOccurs="l" name="Tracks"

•5c>nillable="true" type="sO:ArrayOfTrackDTO" />

</s:sequence>

</s:complexType>

<s:complexType name="ArrayOfTrackDTO">

<s:sequence>

<s:element minOccurs="0" maxOccurs="unbounded"

^name="TrackDTO" nillable="true" type="sO:TrackDTO" />

</s:sequence> </s:complexType>

<s:complexType name="TrackDTO">

<s:sequence>

<s:element minOccurs="l" maxOccurs="l" name="Title"

4j>nillable="true" type="s : string" />

<s:element minOccurs="l" maxOccurs="l" name="Performers"

^>nillable="true" type="sO:ArrayOfString" />

</s:sequence>

</s:complexType>

<s:complexType name="ArrayOfString">

<s:sequence>

<s:element minOccurs="0" maxOccurs="unbounded"

Глава 15. Типовые решения распределенной обработки данных 417

name="string" nillable="true" type="s:string" />

</s:sequence>

</s:complexType>

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

однако оно делает именно то, что нам нужно.

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

носа данных требуется объект-сборщик.

class AlbumAssembler...

public AlbumDTO WriteDTO (Album subject) {

AlbumDTO result = new AlbumDTOO;

result.Artist = subject.Artist.Name;

result.Title = subject.Title; ArrayList

trackList = new ArrayList(); foreach

(Track t in subject.Tracks)

trackList.Add (WriteTrack(t));

result .Tracks = (TrackDTOU) trackList. ToArray (

typeof(TrackDTO) ) ;

return result;

}

public TrackDTO WriteTrack (Track subject) {

TrackDTO result = new TrackDTO(); result.Title =

subject.Title; result.Performers = new String[

subject.Performers.Count];

ArrayList performerList = new ArrayList();

foreach (Artist a in subject.Performers)

performerList.Add (a.Name);

result.Performers = (String!]) performerList.ToArray(

typeof (String));

return result;

}

И наконец, необходимо определение самой службы. Вначале это делается в классе С#.

class AlbumService...

[ WebMethod ]

public AlbumDTO GetAlbum(String key) {

Album result = new AlbumFinder()[key]; if

(result == null)

throw new SoapException ("unable to find album with

key: " + key, SoapException.ClientFaultCode);

else return new AlbumAssembler().WriteDTO(result);

}

Разумеется, это не настоящее определение Web-службы— последнее содержится в

файле WSDL. Далее приведены наиболее важные фрагменты этого определения.

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

<input message="sO .-GetAlbumSoapIn" /> <output

message="sO:GetAlbumSoapOut" /> </operation>

</portType> <message name="GetAlbumSoapIn">

</message> <message name="GetAlbumSoapOut">

<part name="parameters" element="sO:GetAlbumResponse" /:

</message>

<s:element name="GetAlbum">

<s:complexType>

<s:sequence>

<s:element minOccurs="l" maxOccurs="l" name="key"

nillable="true" type="s:string" />

</s:sequence>

</s:complexType>

</s:element>

<s:element name="GetAlbumResponse">

<s:complexType> <s:sequence>

<s:element minOccurs="l" maxOccurs="l"

name="GetAlbumResult" nillable="true" type="sO:AlbumDTO"

</s:sequence>

</s:complexType>

</s:element>

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

статистический политик. Впрочем, в отличие от политиков, оно добросовестно выполня-

ет свою работу. Теперь я могу запустить Web-службу, отослав ей SOAP-сообщение.

?xml version="l.О" encoding="utf-8"?> <soap:Envelope

xmlns:xsi="http://www.w3.org/2001/ ^XMLSenema-instance"

xmlns:xsd="http://www.w3.org/ ^2 001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/ ^soap/envelope/'^

<soap:Body>

<key>aKeyString</key>

</GetAlbum> </soap:Body>

</soap:Envelope>

Приводя этот пример, я хотел продемонстрировать не различные "примочки"

SOAP и .NET, а фундаментальный подход наложения слоев. Спроектируйте приложе-

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

распределенного доступа посредством интерфейсов удаленного доступа и объектов пе-

реноса данных.

Глава 15. Типовые решения распределенной обработки данных 419

Объект переноса данных (Data Transfer Object)

Применяется для переноса данных между процессами в целях

уменьшения количества вызовов

Каждое обращение к интерфейсу удаленного доступа (Remote Facade, 405) связано с

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

вызовов, а значит, каждый вызов должен возвращать как можно больше информации.

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

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

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

одно значение.

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

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

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

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

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

женный на стороне сервера.

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

типового решения термин объект-значение (value object). Я же вкладываю в это понятие

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

Object, 500».

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

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

не пиши объекты переноса данных!" В большинстве случаев объекты переноса данных

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

и set-методов. Ценность этого омерзительного монстра состоит исключительно в воз-

можности передавать по сети несколько элементов информации за один вызов — прием,

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

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

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

чем было запрошено удаленным объектом. Это сделано не случайно: объект переноса

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

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

объекту через какое-то время. Поскольку удаленные вызовы связаны с большими расхо-

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

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

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

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

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

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

му заказу.

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

(Domain Model, 140). Как правило, эти объекты связаны между собой сложной системой

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

объекты домена вообще не следует помещать на сторону клиента — это было бы эквива-

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

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

Поля объектов переноса данных довольно просты. Обычно они содержат значения

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

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

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

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

ектов переноса данных должны "распознаваться" и передающей и принимающей сторо-

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

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

Объект переноса данных рекомендуется проектировать с учетом потребностей конкрет-

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

или экранам сценариев CGI. Более того, в зависимости от конкретного экрана, одному и

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

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

можно применять общий объект переноса данных.

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

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

давать отдельные объекты для каждого запроса? Использование различных объектов пе-

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

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

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

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

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

щего, однако я не возражаю против использования нескольких объектов, если этого тре-

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

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

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

ко других объектов.

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

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

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

Глава 15. Типовые решения распределенной обработки данных 421

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

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

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

мыми. В этом случае приложение получает от клиента один экземпляр объекта переноса

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

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

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

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

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

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

с пониманием этого типового решения как объекта-значения, что и привело к совпаде-

нию названий с моим объектом-значением (Value Object, 500).

Наиболее распространенной формой реализации объекта переноса данных является

множество записей (Record Set, 523) — набор табличных записей, который возвращается

в результате выполнения SQL-запроса. На самом деле множество записей можно

рассматривать как объект переноса данных для базы данных SQL. Подобная схема час-

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

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

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

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

средства для связывания множеств записей с элементами управления. Множество запи-

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

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

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

позаимствован для типового решения модуль таблицы (Table Module, 148).

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

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

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

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

потому что в качестве ключей можно использовать значащие строки. Впрочем, у словаря

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

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

рукой нет генератора объектов, поскольку манипулировать словарем легче, чем писать

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

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

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

Сериализация объекта переноса данных

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

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

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

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

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

встроенные средства для сериализации простых объектов. Например, Java обладает

встроенными средствами сериализации в двоичный формат, a .NET — в двоичный фор-

мат и формат XML. Как правило, наличие встроенных средств значительно упрощает

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

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

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

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

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

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

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

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

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

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

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

нератора.

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

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

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

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

лить только в конкретных условиях.

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

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

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

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

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

объект к компоненту клиента.

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

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

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

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

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

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

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

данных требует гораздо большей пропускной способности соединения (что особенно

верно по отношению к XML), а также может значительно снизить производительность

приложения.

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

ется синхронизация объектов переноса данных на обоих концах соединения. Теоретиче-

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

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

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

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

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

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

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

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

ичное представление объекта. Таким образом, применение двоичного формата сериа-

лизации делает взаимодействие с удаленным клиентом слишком чувствительным к из-

менениям.

Глава 15. Типовые решения распределенной обработки данных 423

Избежать подобных проблем помогают другие схемы сериализации. Одна из них —

это сериализация в формат XML. В большинстве случаев ее можно описать таким обра-

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

Другой возможной альтернативой является сериализация в двоичный формат с исполь-

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

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

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

ми в синхронизации.

Сборка объекта переноса данных из объектов домена

Объект переноса данных не "знает" о том, как взаимодействовать с объектами домена.

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

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

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

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

домена должна оставаться независимой от внешних интерфейсов.

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

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

данных на основе данных домена и наоборот — обновлять модель домена данными из

объекта переноса данных (рис. 15.4). Подобный сборщик можно рассматривать как

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

объектов переноса данных на объекты домена.

Рис. ]5.4. Использование сборщика помогает сохранить независимость модели домена от

объекта переноса данных

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

ми. Главной причиной подобного поведения является необходимость применения одних

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

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

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

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