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

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

Глава 11

Объектно-реляционные

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

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

моделирования

поведения

Единица работы (Unit of Work)

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

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

и разрешает проблемы параллелизма

Извлекая данные из базы данных или записывая в нее обновления, необходимо от-

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

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

а удаленные — уничтожать.

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

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

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

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

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

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

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

чтобы не допустить несогласованности данных.

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

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

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

и будут внесены в базу данных.

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

Базы данных нужны для того, чтобы вносить в них изменения: добавлять новые

объекты или же удалять или обновлять уже существующие. Единица работы — это объект,

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

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

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

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

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

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

мя считывания).

Когда вы решаете зафиксировать сделанные изменения, единица работы определяет,

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

проверку на наличие параллельных операций (с помощью пессимистической автономной

блокировки (Pessimistic Offline Lock, 445) или оптимистической автономной блокировки

(Optimistic Offline Lock, 434)) и записывает изменения в базу данных. Разработчики при-

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

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

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

лостность на уровне ссылок, — единица работы сделает это за них.

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

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

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

При регистрации посредством вызывающего оператора (caller registration) (рис. 11.1)

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

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

ных не будут. Хотя это и допускает появление случайных ошибок со стороны некоторых

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

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

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

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

При регистрации посредством изменяемого объекта (object registration) бремя регистра-

ции перекладывается на методы самого объекта (рис. 11.2). Загружая объект из базы дан-

ных, метод загрузки регистрирует его как "достоверный" (clean). В свою очередь, set-

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

(dirty). Для применения этого способа регистрации единицу работы необходимо передать

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

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

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

Рис. 11.1. Регистрация изменяемого объекта вызывающим оператором

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

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

вызовы функций регистрации в нужных методах. Постепенно это входит в привычку, од-

нако от забывчивости не застрахован никто.

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

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

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

решается средствами аспектно-ориентированного программирования. Кроме того, для

выполнения этой задачи можно произвести последующую обработку (post-processing)

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

ниже, процессор последующей обработки проанализировал все файлы Java с расширени-

ем .classes, отобрал все необходимые методы и вставил в их байт-код вызовы функций

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

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

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

по мере распространения средств аспектно-ориентированного программирования дан-

ная стратегия войдет в широкое употребление.

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

Рис. 11.2. Регистрация изменяемого объекта его же методами

Еще одним распространенным приемом является применение контроллера единицы

работы (unit of work controller), который используется в TOPLink (рис. 11.3). Здесь единица

работы обрабатывает все процедуры считывания из базы данных и регастрирует досто-

верные объекты. Регистрации измененных объектов не происходит. Вместо этого единица

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

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

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

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

вов функций регистрации в объектах домена. Существует и смешанный подход, при

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

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

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

только для чтения.

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

Рис. 11.3. Использование единицы работы в качестве контроллера доступа к базе данных

Регистрация изменяемого объекта посредством вызывающего оператора может ока-

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

только на короткое время. Хорошим примером является тестирование объектов домена,

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

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

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

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

работы, или, что еще лучше, реализация частного случая (Special Case, 511) единицы рабо-

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

Еще одной областью применения единицы работы может стать организация порядка

выполнения обновлений, если СУБД использует проверку целостности на уровне ссы-

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

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

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

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

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

Большинство современных СУБД допускают такую возможность, и в этом случае об

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

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

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

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

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

рассмотрение этого вопроса выходит за рамки настоящей книги. Обычно для реализации

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

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

случае, мне это советовали).

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

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

ние таблиц в одном и том же порядке. Зафиксировав этот порядок в единице работы, вы

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

и той же последовательности.

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

но воспользоваться реестром (Registry, 495), глобальным по отношению к потоку (thread-

scoped). В качестве другого возможного решения можно предложить передачу единицы

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

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

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

Единицу работы хорошо применять и при пакетных обновлениях данных. Суть пакет-

ного обновления (batch update) заключается в отправке нескольких SQL-команд как еди-

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

Это особенно удобно, когда операции обновления, вставки и удаления идут нескончае-

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

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

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

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

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

рации для платформ Microsoft описывается в [30]. Тем не менее, если вы решитесь на по-

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

компиляции выражений.

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

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

щений и мониторами транзакций.

ОСОБЕННОСТИ .NET-РЕАЛИЗАЦИИ

В .NET для реализации единицы работы используется объект DataSet, ле-

жащий в основе отсоединенной модели доступа к данным. Последнее обстоя-

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

решения. Большинство попадавшихся мне единиц работы регистрируют считы-

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

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

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

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

(объекты DataTable), которые, в свою очередь, состоят из столбцов (объекты

DataColumn) и строк (объекты DataRow). Таким образом, объект DataSet

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

зультате выполнения одного или нескольких SQL-запросов. У каждой строки

DataRow есть версии (Current, Original, Proposed) и состояния

(Unchanged, Added, Deleted, Modified). Наличие последних, а также тот

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

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

Назначение

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

няемых над объектами домена, для дальнейшей синхронизации данных, хранящихся

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

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

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

вуют и другие решения.

Пожалуй, наиболее простая альтернатива — явно сохранять объект после каждого

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

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

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

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

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

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

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

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

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

сценарием транзакции (Transaction Script, 133), но они совсем не подходят для модели

предметной области (Domain Model, 140).

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

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

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

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

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

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

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

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

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

изменениях в одном месте. Поэтому вам не придется запоминать море информации, что-

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

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

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

оптимистической автономной блокировки и пессимистической автономной блокировки.

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

Пример: регистрация посредством изменяемого объекта (Java)

Дейвид Раис

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

заданной бизнес-транзакции и затем фиксирует их в базе данных. В нашем примере

у слоя домена есть супертип слоя (Layer Supertype, 491), представленный классом Domain

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

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

class UnitOfWork...

private List newObjects =new ArrayList();

private List dirtyObjects =new ArrayList();

private List removedObjects =new ArrayList();

Состояние этих списков поддерживается методами регистрации. Последние должны

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

катор объекта не равен значению NULL ИЛИ ЧТО измененный объект не был зарегистриро-

ван как новый.

class UnitOfWork...

public void registerNew(DomainObject obj) {

Assert.notNull("id not null", obj.getld());

Assert.isTrue ("object not dirty",

!dirtyObjects.contains(obj));

Assert.isTrue("object not removed",

!removedObjects.contains(obj));

Assert.isTrue("object not already registered new",

!newObjects.contains(obj));

newObjects.add(obj);

}

public void registerDirty(DomainObject obj) {

Assert.notNull ("id not null", obj . getld Ob-

Assert. isTrue ("object not removed",

!removedObjects.contains(obj));

if (!dirtyObjects.contains(obj) &&

!newObjects.contains(obj)) {

dirtyObjects.add(obj); } }

public void registerRemoved(DomainObject obj) {

Assert.notNull("id not null", obj.getld());

if (newObjects.remove(obj)) return;

dirtyObjects.remove(obj); if

(!removedObjects.contains(obj)) {

removedObjects.add(obj ) ; } } public void

registerClean(DomainObject obj) {

Assert.notNull("id not null", obj.getld0);

}

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

Обратите внимание, что в приведенном фрагменте кода метод registerciean о не

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

коллекцию объектов (Identity Map, 216). Использование коллекции объектов необходимо

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

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

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

объектов, метод registerciean () записывал бы в нее зарегистрированные объекты,

загруженные из базы данных. Аналогичным образом метод registerNew помещал бы в

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

жащие уничтожению. Поскольку в нашем случае коллекции объектов нет, без метода

registerciean () можно обойтись. Я встречал реализации этого метода, которые удаляли

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

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

тельны, меняя состояние объекта в списке изменений!

Метод commit () определяет преобразователь данных (Data Mapper, 187), соответст-

вующий каждому из объектов, и вызывает нужный метод отображения. Методы update-

DirtyO и deleteRemovedf) здесь не показаны. Их поведение аналогично поведению

метода insertNew (), текст которого приведен ниже.

class UnitOfWork...

public void commit() {

insertNew(); updateDirty();

deleteRemoved();

} private void

insertNew() {

for (Iterator objects = newObjects.iterator();

objects.hasNext ();) {

DomainObject obj = (DomainObject) objects.next();

MapperRegistry.getMapper(obj.getClass()) .insert (obj); } }

В коде нашего класса UnitOfWork не было реализовано отслеживание считываемых

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

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

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

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

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

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

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

запущенным в данный момент потоком, используя класс j ava. lang. ThreadLocal. Что-

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

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

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

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

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