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

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

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

Назначение

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

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

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

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

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

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

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

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

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

обратными вызовами.

Еще одна альтернатива предполагает непосредственную передачу данных в виде стро-

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

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

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

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

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

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

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

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

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

следнего.

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

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

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

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

(Record Set, 523) в СОМ и .NET. Здесь каждый слой приложения "умеет" обращаться с

данными, представленными в виде множества записей, независимо от того, пришло ли

это множество прямо из базы данных SQL или же было изменено другими слоями. Плат-

форма .NET еще более расширяет данную схему, предоставляя встроенный механизм се-

риализации множеств записей в формат XML.

Хотя эта книга посвящена синхронным системам, объект переноса данных может

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

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

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

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

(Lazy Load, 220). Последнюю необходимо использовать везде, где могут фигурировать ре-

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

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

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

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

В [3] типовое решение объект переноса данных рассматривается под именем объект-

значение (Value Object). Как уже отмечалось, последнее не имеет ничего общего с типо-

вым решением объект-значение (Value Object, 500). Это не более чем досадное совпадение

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

имен; многие используют термин value object в том же значении, что и я. Насколько мне

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

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

Объект-сборщик рассмотрен в [3] под именем сборщик объектов-значений (Value

Object Assembler). Я не стал выносить сборщик в отдельное типовое решение, хотя и при-

менил термин "сборщик", а не преобразователь.

Книга [28] содержит описание объекта переноса данных и нескольких вариантов его

реализации. И наконец, в статье [34] рассмотрены гибкие механизмы сериализации, в ча-

стности переключение между двоичным и текстовым форматами.

Пример: передача информации об альбомах (Java)

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

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

объекты переноса данных, изображенные на рис. 15.6.

Рис. 15.6. Схема классов для объектов переноса данных

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

формации. Необходимые данные из объекта Artist помещаются в объект AlbumDTO, a

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

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

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

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

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

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

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

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

жет содержать в себе более одного элемента данных.

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

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

интерфейс, например интерфейс удаленного доступа.

class AlbumAssembler...

public AlbumDTO writeDTO(Album subject) { AlbumDTO

result = new AlbumDTO();

result.setTitie(subject.getTitie ());

result.setArtist(subject.getArtist().getName());

writeTracks(result, subject); return result; }

private void writeTracks(AlbumDTO result, Album subject) {

List newTracks = new ArrayListf); Iterator it =

subject.getTracks().iterator(); while (it.hasNext ()) {

TrackDTO newDTO = new TrackDTO (); Track

thisTrack = (Track) it.next();

newDTO.setTitle(thisTrack.getTitie());

writePerformers(newDTO, thisTrack);

newTracks.add(newDTO); }

result.setTracks((TrackDTO[]) newTracks.toArray( new

TrackDTO[0])); }

private void writePerformers(TrackDTO dto, Track subject) {

List result = new ArrayList();

Iterator it = subject.getPerformers().iterator();

while (it.hasNext ()) {

Artist each = (Artist) it.nextO;

result.add(each.getName()); }

dto.setPerformers((String[]) result.toArray( new

String[0])); }

Обновление модели содержимым объекта переноса данных немного сложнее. В нашем

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

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

class AlbumAssembler...

public void createAlbum(String id, AlbumDTO source) {

Artist artist = Registry.findArtistNamed(

source.getArtist());

if (artist == null)

throw new RuntimeException("No artist named " +

source.getArtist() ) ;

Album album = new Album(source.getTitle(), artist);

createTracks(source.getTracks(), album);

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

Registry.addAlbum(id, album); }

private void createTracks(TrackDTO[] tracks, Album album) { for

(int i = 0; i < tracks.length; i++) (

Track newTrack = new Track(tracks[i].getTitle());

album.addTrack(newTrack) ;

createPerformers(newTrack, tracks[i].getPerformers() ) ; } }

private void createPerformers(Track newTrack, String[]

^performerArray) {

for (int i = 0; i < performerArray.length; i++) {

Artist performer = Registry.findArtistNamed(

performerArray[i]);

if (performer == null)

throw new RuntimeException("No artist named " +

performerArray[i]);

newTrack.addPerformer(performer); } }

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

сколько решений относительно общей организации создания объектов, в частности объ-

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

объекты исполнителей уже находятся в реестре (Registry, 495), поэтому, если я не могу

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

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

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

са его создания.

class AlbumAssembler...

public void updateAlbum(String id, AlbumDTO source) {

Album current = Registry.findAlbum(id); if (current

== null)

throw new RuntimeException("Album does not exist: " +

source.getTitle ());

if (source.getTitle() != current.getTitle())

current.setTitle (source.getTitle());

if (source.getArtist() != current.getArtist().getName()) {

Artist artist = Registry.findArtistNamed(

source.getArtist());

if (artist == null)

throw new RuntimeException("No artist named " +

source.getArtist() ) ;

current.setArtist(artist) ;

}

updateTracks(source, current);

}

private void updateTracks(AlbumDTO source, Album current) { for

(int i = 0; i < source.getTracks().length; i++) {

current.getTrack(i).setTitle(

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

source.getTrackDTO(i).getTitleО);

current.getTrack(i).clearPerformers();

createPerformers(current.getTrack(i),

source.getTrackDTO(i).getPerformers()); } }

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

или же уничтожить его и заменить новым объектом. При этом необходимо учитывать,

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

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

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

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

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

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

полнителя? Эти вопросы должны решаться отдельно для каждого варианта использова-

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

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

а значит, должен тщательно следить за синхронизацией классов объектов переноса дан-

ных на обоих концах соединения. Если я изменю структуру объекта переноса данных на

стороне сервера и не внесу соответствующие изменения на стороне клиента, попытка пе-

редачи данных приведет к возникновению ошибки. Чтобы сделать процесс передачи

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

в коллекцию.

class TrackDTO...

public Map writeMapO {

Map result = new HashMapO;

result.put ("title", title);

result.put("performers", performers);

return result; } public static TrackDTO

readMap(Map arg) {

TrackDTO result = new TrackDTO();

result.title = (String) arg.get("title");

result.performers = (String!]) arg.get("performers");

return result;

}

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

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

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

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

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

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

Supertypc, 491).

class DataTransferObject...

public Map writeMapReflect() {

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

Map result = null;

try {

Field[] fields = this.getClass () .getDeclaredFields();

result = new HashMapO;

for (int i = 0; i < fields.length; i++)

result.put(fields[i].getName(),

•^fields [i] .get (this) ) ;

} catch (Exception e) {throw new ApplicationException (e);

}

return result;

}

public static TrackDTO readMapReflect(Map arg) {

TrackDTO result = new TrackDTO(); try {

Field[] fields = result.getClass().getDeclaredFields();

for (int i = 0; i < fields.length; i++)

fields[i].set(result, arg.get(fields[i].getName() ) ) ; }

catch (Exception e) {throw new ApplicationException (e) ; )

return result;

Подобные методы хорошо справляются с сериализацией и восстановлением боль-

шинства объектов (хотя вам придется добавить еще несколько строк кода для обработки

стандартных типов данных).

Пример: сериализация с использованием XML (Java)

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

XML, а интерфейсы API хотя и остаются довольно непостоянными, в целом становятся

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

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

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

XML измениться не должна.

Вначале я определяю структуру объекта переноса данных, а затем принимаю реше-

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

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

(marker interface). Для объекта переноса данных выполнение сериализации в двоичный

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

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

например в формат XML.

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

применять для работы с XML, чем стандартные интерфейсы W3C. Ниже приведены ме-

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

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

class AlbumDTO...

Element toXmlElement() {

Element root = new Element("album");

root.setAttribute("title", title);

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

root.setAttribute ("artist", artist);

for (int i = 0; i < tracks.length; i++)

root.addContent(tracks[i].toXmlElement() ) ;

return root; } static AlbumDTO

readXml(Element source) {

AlbumDTO result = new AlbumDTO();

result.setTitle(source.getAttributeValue("title")) ;

result.setArtist(source.getAttributeValue("artist"));

List trackList = new ArrayListO;

Iterator it = source.getChildren("track").iterator();

while (it.hasNext())

trackList.add(TrackDTO.readXml((Element) it.next ()));

result.setTracks((TrackDTO[]) trackList.toArray(

new TrackDTO[0]));

return result;

}

class TrackDTO...

Element toXmlElement() {

Element result = new Element("track");

result.setAttribute("title", title);

for (int i = 0; i < performers.length; i++) {

Element performerElement = new Element("performer");

performerElement.setAttribute("name", performers[i]);

result.addContent(performerElement); }

return result;

}

static TrackDTO readXml(Element arg) { TrackDTO result = new

TrackDTO();

result.setTitle(arg.getAttributeValue("title"));

Iterator it = arg.getChildren("performer").iterator();

List buffer = new ArrayListO; while (it.hasNext()) {

Element eachElement = (Element) it.nextO;

buffer.add(eachElement.getAttributeValue("name")); }

result.setPerformers((String[] ) buffer.toArray(

new String[0]));

return result;

}

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

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

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

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

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

class AlbumDTO...

public void toXmlString(Writer output) {

Element root = toXmlElement();

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

Document doc = new Document(root);

XMLOutputter writer = new XMLOutputter();

try {

writer.output(doc, output); }

catch (IOException e) {

e .printstack.Trace () ; }

}

public static AlbumDTO readXmlString(Reader input) {

try {

SAXBuilder builder = new SAXBuilder();

Document doc = builder.build(input);

Element root = doc.getRootElement();

AlbumDTO result = readXml(root);

return result; }

catch (Exception e) {

e.printStackTrace ();

throw new RuntimeException (); } }

Написать этот код было не слишком сложно. Впрочем, я надеюсь, что средства JAXB

в скором времени вообще сделают его ненужным.

Глава 16

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

для обработки

задач автономного

параллелизма