Фаулер М. Архитектура корпоративных программных приложений
Подождите немного. Документ загружается.
254 Часть II. Типовые решения
Order subject = (Order) abstractSubject;
stmt.setString(2, subject.getCustomer()); }
catch (SQLException e) {
throw new ApplicationException(e); } }
Класс LineitemMapper переопределяет оба приведенных метода. Здесь для вставки
ключа из объекта извлекаются два значения.
class LineitemMapper...
protected String insertStatementString() {
return "INSERT INTO line_items VALUES (?, ?, ?, ?)";
}
protected void insertKey(DomainObjectWithKey subject,
PreparedStatement stmt)
throws SQLException
{
stmt.setLong(1, orderID(subject.getKey 0 ) ) ;
stmt.setLong(2, sequenceNumber(subject.getKey())); }
Кроме того, класс LineitemMapper предоставляет собственную реализацию метода
insert Data для вставки основного содержимого объекта.
class LineitemMapper...
protected void insertData(DomainObjectWithKey subject,
PreparedStatement stmt) throws SQLException {
Lineltem item = (Lineltem) subject;
stmt.setlnt (3, item.getAmount());
stmt.setString(4, item.getProduct() ) ;
}
Подобная реализация вставки данных имеет смысл только в том случае, если боль-
шинство классов используют для хранения ключа одно и то же поле. Если же обработка
значений ключа в производных классах слишком различна, гораздо проще вставить все
данные посредством одной команды.
Вычисление следующего значения ключа также можно разбить на стандартное и пе-
реопределяемое поведение. В стандартном случае можно воспользоваться таблицей клю-
чей, которая упоминалась в предыдущем примере. К сожалению, в ситуации с пунктами
заказов все обстоит гораздо сложнее. Ключ таблицы пунктов заказов является составным
и содержит в себе ключ таблицы заказов. Между тем у класса Lineltem нет ссылки на
класс Order, поэтому объект Lineltem не может быть вставлен в базу данных, если ему
не предоставят нужное значение ключа заказа. Это приводит к необходимости использо-
вания весьма неприятного подхода, связанного с генерацией исключения неподдержи-
ваемой операции (unsupported operation exception).
Глава 12. Объектно-реляционные типовые решения... 255
class LineltemMapper...
public Key insert(DomainObjectWithKey subject) {
throw new UnsupportedOperationException
("Must supply an order when inserting a line item");
}
public Key insert(Lineltem item, Order order) {
try {
Key key = new Key(order.getKey().value(),
getNextSequenceNumber(order));
return performlnsert(item, key);
} catch (SQLException e) {
throw new ApplicationException(e); } }
Разумеется, этого можно было избежать, создав обратную ссылку класса пунктов за-
казов на класс заказов (вследствие чего связь между классами превратилась бы в двуна-
правленную). Тем не менее в данном примере я решил продемонстрировать, что следует
делать, если обратной ссылки нет.
Передав методу insert Key объект заказа, из него легко извлечь значение ключа, тем
самым получив первый элемент ключа для пункта заказа. Но как узнать порядковый но-
мер нового пункта заказа? Для этого необходимо определить следующий доступный
номер пункта заказа, применив SQL-функцию МАХ ИЛИ же просмотрев пункты данного
заказа, хранящиеся в оперативной памяти. В этом примере используется второй вариант.
class LineltemMapper...
private Long getNextSequenceNumber(Order order) {
loadAHLineltemsFor (order) ; Iterator it =
order.getltems().iterator(); Lineltem
candidate = (Lineltem) it.nextO; while
(it.hasNext ()) {
Lineltem thisltem = (Lineltem) it.nextO;
if (thisltem.getKey() == null) continue;
if (sequenceNumber(thisltem) > sequenceNumber(
candidate)) candidate = thisltem; } return new
Long(sequenceNumber(candidate) + 1);
}
private static long sequenceNumber(Lineltem li) {
return sequenceNumber(li.getKey());
}
// метод сравнения может не сработать из-за несохраненных
// значений ключа, равных null
protected String keyTableRowO {
throw new UnsupportedOperationException() ; }
256 Часть II. Типовые решения
Этот алгоритм был бы гораздо лучше, если бы я воспользовался методом Collec-
tions .max, однако, поскольку у нас может быть (и будет), как минимум, одно значение
ключа, равное NULL, данный метод не подойдет.
Обновление и удаление
После всех перенесенных мучений операции обновления и удаления кажутся просто
безобидными. Опять же, у нас есть абстрактный метод для стандартных случаев и пере-
определенный метод для частных случаев.
Обновление данных выполняется следующим образом:
class AbstractMapper...
public void update(DomainObjectWithKey subject) {
PreparedStatement stmt = null; try {
stmt = DB.prepare(updateStatementString());
loadUpdateStatement(subject, stmt);
stmt.execute() ; } catch (SQLException e) {
throw new ApplicationException(e) ; }
finally {
DB.cleanup(stmt); }
}
abstract protected String updateStatementString();
abstract protected void loadUpdateStatement(
DomainObjectWithKey subject, PreparedStatement stmt)
throws SQLException;
class OrderMapper...
protected void loadUpdateStatement(
^DomainObjectWithKey subject, PreparedStatement stmt)
throws SQLException
{
Order order = (Order) subject;
stmt.setString(1, order.getCustomer() ) ;
stmt.setLong(2, order.getKey().longValue()); }
protected String updateStatementString() {
return "UPDATE orders SET customer = ? WHERE id = ?"; }
class LineltemMapper...
protected String updateStatementString() {
return
"UPDATE line_items " + " SET amount =
?, product = ? " + WHERE orderld = ? AND
seq = ?"; }
protected void loadUpdateStatement(
DomainObjectWithKey subject, PreparedStatement stmt)
Глава 12. Объектно-реляционные типовые решения... 257
throws SQLException
{
stmt.setLong(3, orderID(subject.getKey()));
stmt.setLong(4, sequenceNumber(subject.getKey() ) ) ;
Lineltem li = (LineItem) subject;
stmt.setInt(1, li.getAmount());
stmt.setstring(2, li.getProduct() ) ;
}
А вот как происходит удаление:
class AbstractMapper...
public void delete(DomainObjectWithKey subject) {
PreparedStatement stmt = null; try {
stmt = DB.prepare(deleteStatementString());
loadDeleteStatement(subject, stmt);
stmt.execute(); } catch (SQLException e) {
throw new ApplicationException(e) ; }
finally {
DB.cleanup(stmt); }
}
abstract protected String deleteStatementString ();
protected void loadDeleteStatement(DomainObjectWithKey
subject, PreparedStatement stmt)
throws SQLException
{
stmt.setLong(1, subject.getKey().longValue() );
}
class OrderMapper...
protected String deleteStatementString() {
return "DELETE FROM orders WHERE id = ?";
}
class LineltemMapper...
protected String deleteStatementString() {
return "DELETE FROM line_items WHERE orderid = ? AND
seq = ?"; }
protected void loadDeleteStatement(DomainObjectWithKey
subject, PreparedStatement stmt) throws SQLException
{
stmt.setLong(1, orderlD(subject.getKey()));
stmt.setLong(2, sequenceNumber(subject.getKey())); }
258 Часть II. Типовые решения
Отображение внешних ключей (Foreign Key Mapping)
Отображает ассоциации между объектами на ссылки внешнего ключа
между таблицами базы данных
Объекты могут ссылаться непосредственно друг на друга с помощью объектных ссы-
лок (object references). Даже самая простая объектно-ориентированная система обяза-
тельно содержит группу объектов, связанных между собой всеми возможными и невоз-
можными способами. Разумеется, при сохранении объектов в базе данных необходимо
позаботиться и о сохранении всех ссылок. К сожалению, поскольку содержимое объек-
тов специфично для конкретного экземпляра запущенной программы, сохранение зна-
чений "в чистом виде" ничего не даст. Данную проблему еще более усложняет тот факт,
что объекты могут содержать коллекции ссылок на другие объекты. Подобная структура
нарушает определение первой нормальной формы реляционных баз данных.
Типовое решение отображение внешних ключей отображает объектную ссылку на
внешний ключ базы данных.
Принцип действия
Первая мысль, возникающая по поводу данной проблемы, — воспользоваться полем
идентификации (Identity Field, 237). Действительно, каждому объекту соответствует опре-
деленное значение ключа таблицы базы данных. Если два объекта связаны между собой
некоторой ассоциацией, в базе данных ее можно заменить внешним ключом. Например,
если вы сохраняете в базе данных запись об альбоме, в эту же строку можно поместить и
идентификатор исполнителя, связанного с этим альбомом (рис. 12.1).
Рассмотренный случай довольно прост. А как же быть, если речь идет о ссылке на
коллекцию объектов? В базе данных нельзя сохранить коллекцию ключей, поэтому на-
правление ссылки придется изменить. Таким образом, имея коллекцию композиций
альбома, необходимо поместить внешний ключ альбома в запись о каждой композиции
(рис. 12.2 и 12.3). Основные сложности подобных ситуаций связаны с обновлением.
В рамках обновления в коллекции композиций альбома могут произойти изменения,
Глава 12. Объектно-реляционные типовые решения... 259
связанные с удалением или добавлением новых объектов. Как определить, какие измене-
ния должны быть внесены в базу данных? Для этого можно воспользоваться тремя спо-
собами: удалением и вставкой, добавлением обратного указателя и операцией сравнения.
Рис. 12.2. Отображение коллекции на внешний ключ
Первый, и наиболее простой, способ — удалить из базы данных все композиции, ссы-
лающиеся на заданный альбом, и затем вставить в нее те композиции, которые на дан-
ный момент находятся в альбоме. На первый взгляд это звучит не очень умно, особенно
если набор композиций на самом деле не изменился. Тем не менее эта логика проста в
реализации и, кроме того, работает гораздо надежнее других способов. Следует также от-
метить, что данный способ можно применить только в том случае, если композиции свя-
заны отображениями зависимых объектов (Dependent Mapping, 283), а значит, являются
полностью зависимыми от объекта-альбома и на них нельзя ссылаться извне.
Добавление обратного указателя подразумевает создание ссылки композиции на аль-
бом, в результате чего связь между этими объектами становится двунаправленной. Разу-
меется, это изменяет объектную модель, однако позволяет значительно упростить обнов-
ление данных путем простого обновления однозначных полей "с другой стороны" ссылки.
Рис. 12.3. Классы и таблицы, связанные многозначной ссылкой
Если ни один из перечисленных способов вам не подойдет, попробуйте провести
сравнение. В качестве эталона можно воспользоваться текущим состоянием базы данных
или же множеством данных, которое было считано при первой загрузке объекта. В пер-
вом случае от вас требуется еще раз считать из базы данных коллекцию композиций, вхо-
дящих в альбом, и затем сравнить их с текущим содержимым альбома. Все композиции
считанного множества данных, которых нет в альбоме, должны быть удалены из базы
данных, а все композиции альбома, которых нет в считанном множестве данных, должны
быть добавлены в базу данных.
Чтобы сравнить текущее состояние коллекции с множеством данных, которое было
считано при первой загрузке объекта, необходимо реализовать сохранение считываемых
данных. Это более предпочтительный способ, поскольку он избавляет от необходимости
дополнительного обращения к базе данных. Впрочем, обращение к базе данных может
понадобиться, если вы используете
оптимистическую автономную блокировку (Optimistic
Offline Lock, 434).
В более общем случае каждый объект, добавляемый в коллекцию, должен быть
проверен на предмет того, является ли он новым объектом. Это можно установить по
наличию ключа; если у добавленного объекта нет ключа, значит, он новый и его следует
вставить в базу данных. Для реализации подобной проверки хорошо воспользоваться
единицей работы (Unit of Work, 205), поскольку она автоматически вставляет в базу
данных новые объекты. В любом случае после выполнения этих действий в базе данных
необходимо найти строку, соответствующую добавленной композиции, и обновить ее
внешний ключ так, чтобы он указывал на текущий альбом.
При удалении композиции из содержимого альбома необходимо знать, была ли она
перемещена в другой альбом, оставлена без альбома или окончательно удалена из базы
данных. Если композиция была перемещена в другой альбом, ее внешний ключ должен
быть обновлен при обновлении альбома. Если композиция была оставлена без альбома,
ее внешнему ключу необходимо присвоить значение NULL. И наконец, если композиция
была удалена, ее необходимо удалить вместе со всеми другими удаляемыми записями.
Выполнять удаление значительно проще, если наличие обратной ссылки обязательно
(как в нашем примере, когда каждая композиция должна принадлежать какому-нибудь
260 Часть II. Типовые решения
Глава 12. Объектно-реляционные типовые решения... 261
альбому). В этом случае вам не придется определять, какие композиции были удалены из
альбома, поскольку значения их внешних ключей будут обновлены при обновлении аль-
бомов, в которые эти композиции были перемещены.
Обратная ссылка может быть неизменяемой (т.е. композиция не может быть переме-
щена в другой альбом). В этом случае добавление композиции в альбом всегда означает
вставку строки в базу данных, а удаление из альбома — удаление соответствующей строки
из базы данных. Это еще более упрощает обновление коллекций.
Работая с базой данных, необходимо следить за наличием циклических ссылок.
Предположим, нужно загрузить заказ, ссылающийся на покупателя (который тоже будет
загружен). Каждому покупателю соответствует множество платежей (сведения о котором
тоже будут загружены), а каждый платеж ссылается на оплачиваемые им заказы. Послед-
нее множество может включать в себя упомянутый заказ. Таким образом, будет загружен
и этот заказ, после чего все повторяется снова и снова.
Во избежание подобной мешанины можно воспользоваться одним из двух способов
создания объектов. Многие предпочитают применять конструкторы с аргументами, что-
бы создаваемые объекты были полностью загружены данными. В этом случае придется
прибегнуть к загрузке по требованию (Lazy Load, 220), чтобы цикл загрузки прерывался в
нужных местах. Если этого не сделать, вам грозит переполнение стека. Впрочем, если ре-
зультаты тестирования оказались вполне приличными, без применения загрузки по тре-
бованию можно обойтись.
Второй возможный вариант — создать пустой объект и сразу же поместить его в кол-
лекцию объектов (Identity Map, 216). В этом случае при повторной ссылке на объект кол-
лекция объектов сообщит, что он уже был загружен, и цикл будет прерван. Разумеется,
объекты, создаваемые подобным образом, не заполнены данными, однако по окончании
загрузки они будут содержать в себе все, что нужно. Это позволяет избежать описания ча-
стных случаев загрузки по требованию, что было бы крайне утомительно, если нужно
всего лишь корректно загрузить объект.
Назначение
Отображение внешних ключей может применяться для моделирования практически
всех видов связей между классами. Наиболее распространенный случай, когда отображе-
ние внешних ключей применить нельзя, — это связи типа "многие ко многим". Внешние
ключи являются одномерными значениями, а из определения первой нормальной фор-
мы следует, что в одном поле нельзя хранить множественные значения внешних ключей.
В этом случае вместо отображения внешних ключей необходимо воспользоваться отобра-
жением с помощью таблицы ассоциаций (Association Table Mapping, 269).
Если у вас есть поле коллекции без обратного указателя, подумайте о том, не сделать
ли "множественную сторону" ссылки отображением зависимых объектов. Это значитель-
но упростит обработку коллекции.
Если связанный объект является объектом-значением (Value Object, 500), вместо ото-
бражения внешних ключей следует воспользоваться внедренным значением (Embedded
Value, 288).
262 Часть II. Типовые решения
Пример: однозначная ссылка (Java)
Рассмотрим наиболее простой случай, когда объект-альбом ссылается на своего ис-
полнителя.
class Artist...
private String name;
public Artist(Long ID, String name) {
super(ID);
this.name = name; }
public String getNameO {
return name; } public void
setName(String name) {
this.name = name;
}
class Album...
private String title;
private Artist artist;
public Album(Long ID, String title, Artist artist) {
super(ID);
this.title = title;
this.artist = artist; }
public String getTitleO {
return title; } public void
setTitle(String title) {
this.title = title; }
public Artist getArtistO {
return artist; } public void
setArtist(Artist artist) {
this.artist = artist; )
Процесс загрузки альбома показан на рис. 12.4. Когда преобразователь AlbumMapper
получает указание загрузить альбом, он выполняет запрос к базе данных и возвращает ре-
зультирующее множество данных, соответствующее заданному альбому. Затем преобра-
зователь выполняет запрос к результирующему множеству данных и извлекает оттуда
значение внешнего ключа исполнителя. Теперь преобразователь может загрузить объект
альбома найденными значениями. Если объект исполнителя уже был загружен в память,
он будет извлечен из кэша; в противном случае он будет загружен из базы данных так, как
это делалось для альбома.
Рис. 12.4. Процесс загрузки однозначного поля
Для работы с коллекцией объектов метод поиска применяет абстрактное поведение.
class AlbumMapper...
public Album find(Long id) {
return (Album) abstractFind(id);
} protected String findStatement()
{
return "SELECT ID, title, artistID FROM albums WHERE ID =
?"; }
class AbstractMapper...
abstract protected String findStatement();
protected DomainObject abstractFind(Long id) {
DomainObject result = (DomainObject) loadedMap.get(id);
if (result != null) return result; PreparedStatement
stmt = null; ResultSet rs = null; try {
stmt = DB.prepare(findStatement ());
stmt.setLong(1, id.longValue());
rs = stmt.executeQuery();
rs.next();
result = load(rs);
Глава 12. Объектно-реляционные типовые решения... 263