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

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

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

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

класса-владельца. И наконец, в случае шлюза таблицы данных (Table Data Gateway, 167)

зависимого класса не будет вообще; всю обработку зависимых данных будет осуществ-

лять класс-владелец.

В большинстве случаев вместе с объектом-владельцем загружаются и его зависимые

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

используются нечасто, можно применить загрузку по требованию (Lazy Load, 220), чтобы

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

Важным свойством зависимого объекта является то, что он не имеет поля идентифи-

кации (Identity Field, 237) и, следовательно, не заносится в коллекцию объектов (Identity

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

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

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

владельцем.

Зависимый объект может быть владельцем другого зависимого объекта. В этом случае

владелец первого зависимого объекта отвечает и за второй зависимый объект. Вообще го-

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

ным первичным владельцем.

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

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

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

них ключей объектов, которые имеют того же владельца). Как следствие этого, ни один

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

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

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

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

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

тами применяют операцию композиции.

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

владелец и на эти объекты нет внешних ссылок, их обновление может быть реализовано

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

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

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

Это избавит вас от необходимости анализировать, что было удалено, а что добавлено в

коллекцию зависимых объектов владельца.

Во многих отношениях зависимые объекты напоминают объекты-значения (Value

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

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

метода проверки на равенство). Главное же различие между теми и другими состоит в

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

обычных. "Зависимая" природа таких объектов проявляется только при отображении на

базу данных.

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

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

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

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

Глава 12. Объектно-реляционные типовые решения... 285

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

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

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

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

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

Назначение

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

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

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

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

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

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

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

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

дующих условий:

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

• на зависимый объект может ссылаться только его владелец.

Существует направление объектно-ориентированного проектирования, которое ис-

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

предметной области (Domain Model, 140). Я же предпочитаю рассматривать отображение

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

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

стности, я избегаю создавать большие графы зависимых объектов. Как известно, на зави-

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

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

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

работы (Unit of Work, 205). Стратегия удаления и повторной вставки окажется бесполез-

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

единица работы не контролирует зависимые объекты. Майк Реттиг (Mike Rettig) расска-

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

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

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

лись "осиротевшие" строки, которые испортили всю картину тестирования.

Пример: альбомы и композиции (Java)

В модели предметной области, показанной на рис. 12.7, объект-альбом содержит кол-

лекцию композиций. В этом простом (и, надо сказать, совершенно бесполезном) прило-

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

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

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

типовое решение.)

Рис. 12.7. К альбому, ссылающемуся на композиции, нельзя не применить

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

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

class Track...

private final String title;

public Track(String title) {

this.title = title; }

public String getTitleO {

return title;

}

Список композиций хранится в классе альбома.

class Album...

private List tracks = new ArrayListO;

public void addTrack(Track arg) {

tracks.add(arg); } public void

removeTrack(Track arg) {

tracks.remove(arg); } public

void removeTrack(int i) {

tracks.remove(i) ; }

public Track [] getTracksO {

return (Track[]) tracks.toArray(new Track[tracks.size()]);

)

Класс AlbumMapper выполняет все SQL-операции для работы с композициями и по-

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

композиций.

class AlbumMapper...

protected String findStatement() {

return

"SELECT ID, a.title, t.title as trackTitle" + FROM

albums a, tracks t" + WHERE a.ID = ? AND t.albumID =

a.ID" + ORDER BY t.seq"; }

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

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

Глава 12. Объектно-реляционные типовые решения... 287

class AlbumMapper...

protected DomainObject doLoad(Long id, ResultSet rs)

throws SQLException {

String title = rs.getString(2);

Album result = new Albumfid, title);

loadTracks(result, rs) ;

return result; )

public void loadTracks(Album arg, ResultSet rs)

throws SQLException {

arg.addTrack(newTrack(rs) ) ;

while (rs.next ()) {

arg.addTrack(newTrack(rs));

} )

private Track newTrack(ResultSet rs) throws

SQLException {

String title = rs.getString(3);

Track newTrack = new Track (title);

return newTrack;

}

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

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

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

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

class AlbumMapper...

public void update(DomainObject arg) {

PreparedStatement updateStatement = null;

try {

updateStatement = DB.prepare("UPDATE albums

SET title = ? WHERE id = ?");

updateStatement.setLong(2, arg.getID().longValue());

Album album = (Album) arg;

updateStatement.setString(l, album.getTitie());

updateStatement.execute() ; updateTracks(album); }

catch (SQLException e) {

throw new ApplicationException(e) ; }

finally {DB.cleanup(updateStatement); } )

public void updateTracks(Album arg) throws SQLException {

PreparedStatement deleteTracksStatement = null; try {

deleteTracksStatement = DB.prepare("DELETE from tracks

"bWHERE albumID = ?");

deleteTracksStatement.setLong(1,

arg.getID().longValue());

deleteTracksStatement.execute() ;

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

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

Track track = arg.getTracks()[i];

insertTrack(track, i + 1, arg); }

} finally {DB.cleanup(deleteTracksStatement) ; } } public void

insertTrack(Track track, int seq, Album album)

throws SQLException {

PreparedStatement insertTracksStatement = null;

try {

insertTracksStatement =

DB.prepare("INSERT INTO tracks (seq, albumID, title)

VALUES (?, ?, ?)");

insertTracksStatement.setlnt (1, seq);

insertTracksStatement.setLong(2,

album.getlDO .longValue() ) ;

insertTracksStatement.setstring(3, track.getTitle ());

insertTracksStatement.execute(); } finally

{DB.cleanup(insertTracksStatement); } }

Внедренное значение (Embedded Value)

Отображает объект на несколько полей таблицы, соответствующей

другому объекту

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

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

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

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

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

ных значений.

Типовое решение внедренное значение отображает значения полей объекта на поля за-

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

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

Глава 12. Объектно-реляционные типовые решения... 289

таблице поля этих объектов (диапазон дат и денежное значение) будут отображаться на

поля таблицы должностей, а не на записи собственных таблиц.

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

На самом деле все очень просто. Когда объект-владелец (должность) загружается в ба-

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

мые объекты (диапазон дат и денежное значение). Зависимые классы не имеют собст-

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

владельцем. Для большей наглядности внедренное значение можно рассматривать как ча-

стный случай отображения зависимых объектов (Dependent Mapping, 283), где значение

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

Назначение

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

применения гораздо труднее.

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

простые и понятные объекты-значения (Value Object, 500) наподобие денежных значений

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

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

коллекций объектов (Identity Map, 216). Вообще говоря, все объекты-значения должны

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

таблицы.

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

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

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

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

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

зом, стоит подумать о том, чтобы хранить их в одной таблице. Еще один спорный момент

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

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

и не используете для этого отдельной базы данных.

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

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

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

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

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

нение зависимого объекта автоматически помечает его владельца как "измененного" —

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

равносильно их замене в коллекции владельца.

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

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

(связь типа "один к одному"). Иногда внедренное значение применяют и в тех случаях,

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

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

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

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

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

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

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

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

просу выбора между этими двумя типовыми решениями. Огромным преимуществом вне-

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

объекта. Хотя сериализация объектов с использованием XML, а также появление допол-

нительных компонентов SQL, основанных на XML, могут изменить ситуацию в будущем,

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

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

ния отчетов.

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

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

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

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

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

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

различными именами. В технологии TOPLink его называют агрегированным отображени-

ем (aggregate mapping), а в Visual Age — компоновщиком (composer).

Пример: простой объект-значение (Java)

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

няется посредством внедренного значения. Для начала создадим простой класс Product

offering ("Предложение на продажу"), содержащий перечисленные ниже поля.

class ProductOffering...

private Product product;

private Money baseCost;

private Integer ID;

Здесь поле ID является полем идентификации (Identity Field, 237), а поле product —

отображением обычной записи о товаре. Для отображения базовой стоимости товара

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

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

активной записи (Active Record, 182).

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

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

се ProductOf f ering. У класса Money подобных методов не будет. Покажем, как выгля-

дит метод загрузки.

class ProductOffering...

public static ProductOffering load(ResultSet rs) {

try {

Integer id = (Integer) rs.getObject("ID");

Глава 12. Объектно-реляционные типовые решения... 291

BigDecimal baseCostAmount = rs.getBigDecimal(

"base_cost_amount");

Currency baseCostCurrency = Registry.getCurrency(

rs.getString("base_cost_currency") ) ;

Money baseCost = new Money(baseCostAmount,

baseCostCurrency);

Integer productID = (Integer) rs.getObject("product"); Product

product = Product.find ( (Integer) rs.getObject( "product") );

return new ProductOffering(id, product, baseCost); }

catch (SQLException e) {

throw new ApplicationException (e); } }

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

риацию стандартных методов.

class ProductOffering...

public void update() {

PreparedStatement stmt = null;

try {

stmt = DB.prepare(updateStatementString) ;

stmt.setBigDecimal(1, baseCost.amount() ) ;

stmt.setString(2, baseCost.currency() .code() ) ;

stmt.setlnt(3, ID.intValue() ) ; stmt.execute() ; }

catch (Exception e) {

throw new ApplicationException(e); }

finally {DB.cleanup(stmt);} }

private String updateStatementString =

"UPDATE product_offerings" + " SET

base_cost_amount = ?, base_cost_currency

= ? " + WHERE id = ?";

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

Сериализованный крупный объект (Serialized LOB)

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

объект (Large Object — LOB) и помещает его в поле базы данных

{Иерархия}

В объектных моделях часто встречаются сложные графы небольших объектов. Боль-

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

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

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

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

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

уровне иерархии, что и данный, и т.п.

С реляционными базами данных дело обстоит намного сложнее. Основная схема как

будто проста — таблица организации с внешними ключами "предков" соответствующих

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

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

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

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

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

(Large Object — LOB). Соответствующее типовое решение получило название крупного се-

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

мементо (Memento) [20].

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

Существует два вида крупных объектов: крупный двоичный объект (binary LOB —

BLOB) и крупный символьный объект (character LOB— CLOB). Объекты BLOB проще соз-

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

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

Глава 12. Объектно-реляционные типовые решения... 293

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

соответствующем поле таблицы.

Преимуществами объектов BLOB являются простота кодирования (если они поддер-

живаются средой разработки) и небольшие размеры занимаемого пространства. Недос-

татки же заключаются в том, что для применения объектов BLOB используемая СУБД

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

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

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

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

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

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

протяжении долгого времени.

Альтернативой BLOB являются уже упоминавшиеся объекты CLOB. В этом случае

граф объектов сериализуется в текстовую строку, содержащую всю необходимую инфор-

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

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

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

анализатора. Кроме того, обработка символьных объектов обычно занимает больше вре-

мени, чем обработка двоичных.

Большую часть недостатков объектов CLOB можно преодолеть путем сериализации

в формат XML Анализаторы XML доступны всем, поэтому писать собственный анализатор

вам не придется. Кроме того, в последние годы XML превратился в общепринятый стан-

дарт и для работы с этим форматом данных постоянно появляется все больше и больше

программных средств. К сожалению, использование XML не решает проблемы с занимае-

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

тов на языке XML слишком "многословны". Данную проблему можно решить путем ис-

пользования сжатого формата XML в качестве объекта BLOB; разумеется, это лишит его

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

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

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

содержались сведения о покупателе. Не помещайте LOB с данными покупателя в таблицу

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

труднит обновление одного из них. (Тем не менее этот подход может оказаться весьма

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

находились в момент размещения заказа; это избавит от необходимости создавать вре-

менные отношения.) Если вы хотите, чтобы обновление данных о покупателе выполня-

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

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

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

из двух полей — идентификатора и LOB; это вполне нормально.

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

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

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

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

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

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