Фаулер М. Архитектура корпоративных программных приложений
Подождите немного. Документ загружается.
314 Часть II. Типовые решения
Принцип действия
Данное типовое решение подразумевает создание отдельной таблицы для каждого
конкретного класса иерархии наследования. При этом каждая таблица содержит столб-
цы, соответствующие полям конкретного класса и всех его "предков", а потому поля су-
перкласса дублируются во всех таблицах его производных классов. Как и остальные схе-
мы отображения иерархии наследования, данное типовое решение основано на фунда-
ментальном принципе преобразователей наследования (Inheritance Mappers, 322).
Используя наследование с таблицами для каждого конкретного класса, необходимо об-
ращать особое внимание на ключи. В данном случае они должны быть уникальны не
только в пределах таблицы, но и в пределах всей иерархии. Классическим примером не-
обходимости подобного решения является ситуация, когда для коллекции игроков ис-
пользуется поле идентификации (Identity Field, 237) с ключами, уникальными в пределах
таблиц. Если значения ключей повторяются в разных таблицах конкретных классов, од-
ному значению ключа может соответствовать целый набор строк. В этом случае вам по-
надобится система распределения ключей, которая будет следить за использованием их
значений в разных таблицах; кроме того, вы не сможете полагаться на механизм уни-
кальности первичных ключей базы данных.
Подобная ситуация может стать особенно неприятной, если вы работаете с базами
данных, используемыми другими системами. В большинстве таких случаев вы не сможе-
те гарантировать уникальность ключей в пределах таблиц. Чтобы избежать такого рода
проблем, вам придется отказаться от использования полей суперклассов либо применить
составной ключ, который будет включать в себя идентификатор таблицы.
Ситуацию можно упростить, если вообще не создавать полей, принадлежащих супер-
классу, однако это потребует полного пересмотра объектной модели. Существует и аль-
тернативный вариант: определить открытый интерфейс с методами доступа к супертипу,
а в реализации использовать несколько закрытых полей для каждого конкретного типа.
В этом случае интерфейс будет комбинировать значения закрытых полей. Если открытый
интерфейс возвращает одномерное значение, он будет выбирать из значений закрытых
полей то, которое не равно NULL. ЕСЛИ же открытый интерфейс возвращает значение-
коллекцию, он будет использовать объединение значений закрытых полей.
Для представления составного ключа в качестве значения поля идентификации можно
использовать специальный объект ключа. Чтобы обеспечить уникальность по всей ие-
рархии наследования, такой ключ использует сочетание первичного ключа таблицы и ее
имени.
Описанная проблема тесно связана с проблемой целостности на уровне ссылок. В ка-
честве примера рассмотрим объектную модель, изображенную на рис. 12.10. Чтобы реа-
лизовать целостность на уровне ссылок, нужно создать таблицу отношений, которая бу-
дет содержать внешние ключи благотворительных акций и игроков. Но в базе данных нет
таблицы игроков, поэтому для поля внешнего ключа нельзя создать ограничение целост-
ности на уровне ссылок, которое бы применялось и для футболистов, и для игроков в
крикет. В этом случае придется либо пренебречь целостностью на уровне ссылок, либо
использовать несколько таблиц отношений (по одной на каждую реальную таблицу базы
данных). Проблема становится еще более серьезной, если мы не сможем гарантировать
уникальность ключа в пределах иерархии.
Рис. 12.10. Объектная модель, иллюстрирующая сложность реализации целостности на уровне ссылок при
использовании типового решения наследование с таблицами для каждого конкретного класса
Выполняя поиск игроков с помощью оператора SELECT, ВЫ ДОЛЖНЫ просмотреть все
таблицы, чтобы узнать, какая из них содержит нужное значение. Для этого придется со-
вершить несколько запросов либо выполнить внешнее соединение. И то и другое реше-
ние крайне негативно отражается на производительности. Разумеется, вы не страдаете от
падения производительности, когда точно знаете, какой класс вам нужен, однако для по-
вышения производительности необходимо использовать только конкретные классы.
Данное типовое решение часто рассматривают как разновидность наследования с таб-
лицами для каждого листа (leaf table inheritance). Некоторые разработчики предпочитают
создавать по одной таблице не для каждого конкретного класса, а для каждого листа ие-
рархии наследования. Если в иерархии нет конкретных суперклассов, данные принципы
отображения полностью совпадают. Впрочем, даже если подобные классы и есть, разница
все равно невелика.
Назначение
Для отображения иерархии наследования на реляционную базу данных могут приме-
няться наследование с таблицами для каждого конкретного класса, наследование с таблица-
ми для каждого класса (Class Table Inheritance, 305) или наследование с одной таблицей
(Single Table Inheritance, 297).
Преимущества наследования с таблицами для каждого конкретного класса перечис-
лены ниже.
• Каждая таблица является замкнутой и не содержит ненужных полей, вследствие
чего ее удобно использовать в других приложениях, не работающих с объектами.
• При считывании данных посредством конкретных преобразователей не нужно
выполнять соединений.
• Доступ к таблице осуществляется только в случае доступа к конкретному классу,
что позволяет распределить нагрузку по всей базе данных.
Разумеется, данное типовое решение имеет и слабые стороны.
• Первичные ключи могут быть неудобны в обработке.
• Отсутствует возможность моделировать отношения между абстрактными классами.
Глава 12. Объектно-реляционные типовые решения... 315
316 Часть II. Типовые решения
• Если поля классов домена перемещаются в суперклассы или производные классы,
придется вносить изменения в определения таблиц. Эти изменения будут не так
часты, как в случае наследования с таблицами для каждого класса, однако их нельзя
просто игнорировать, как было в случае с наследованием с одной таблицей.
• Если в суперклассе будет изменено какое-нибудь поле, понадобится изменить ка
ждую таблицу, имеющую данное поле, поскольку поля суперкласса дублируются
во всех таблицах его производных классов.
• Абстрактному методу поиска придется просматривать все таблицы производных
классов, что потребует большого количества обращений к базе данных (либо вы
полнения весьма странных соединений).
Запомните: все три упомянутых типовых решения могут спокойно сосуществовать в
пределах одной иерархии. Например, вы можете отобразить один или два производных
класса посредством наследования с таблицами для каждого конкретного класса, а к осталь-
ным применить наследование с одной таблицей.
Пример: конкретные классы игроков (С#)
Рассмотрим реализацию модели, описанной в этом разделе. Как и в предыдущих
примерах отображения иерархии наследования, я воспользуюсь фундаментальной кон-
цепцией преобразователей наследования (Inheritance Mappers, 322), схема которой приве-
дена на рис. 12.11.
Каждый преобразователь ссылается на таблицу, являющуюся источником данных для
конкретного класса. Таблицы представлены объектами DataTable и хранятся в объекте
ADO.NET DataSet.
class Mapper...
public Gateway Gateway;
private IDictionary identityMap = new Hashtable();
public Mapper (Gateway gateway) {
this.Gateway = gateway; }
private DataTable table {
get {return Gateway.Data.Tables[TableName];}
} abstract public String TableName {get;}
Значением свойства Data класса Gateway является объект DataSet. Его содержимое
может быть загружено путем выполнения соответствующих запросов.
class Gateway...
public DataSet Data = new DataSet();
Каждый конкретный преобразователь должен ссылаться на таблицу, в которой хра-
нятся данные соответствующего класса.
Глава 12. Объектно-реляционные типовые решения... 317
class
CricketerMapper...
public override String TableName {
get {return "Cricketers";}
Рис. 12.11. Универсальная схема классов для преобразователей наследования
Класс piayerMapper содержит по одному полю на каждый конкретный класс преоб-
разователя.
class PiayerMapper...
private BowlerMapper bmapper;
private CricketerMapper cmapper;
private FootballerMapper fmapper;
public PiayerMapper (Gateway gateway) : base (gateway) {
318 Часть II. Типовые решения
bmapper
=
new
BowlerMapper(Gateway) ;
cmapper
=
new
CricketerMapper(Gateway);
fmapper
=
new
FootballerMapper(Gateway);
)
Загрузка объекта из базы данных
У каждого конкретного класса преобразователя есть метод поиска, который возвра-
щает объект по значению его первичного ключа.
class CricketerMapper...
public Cricketer Find(long id) {
return (Cricketer) AbstractFind(id); }
Абстрактный метод суперкласса находит строку с указанным идентификатором, соз-
дает новый объект домена нужного типа и заполняет его содержимым с помощью метода
загрузки (последний будет описан немного позднее).
class Mapper...
public DomainObject AbstractFind(long id) {
DataRow row = FindRow(id);
if (row == null) return null;
else {
DomainObject result = CreateDomainObject();
Load(result, row); return result;
} } private DataRow FindRowdong
id) {
String filter = String.Format("id = {0}", id);
DataRow[] results = table.Select(filter);
if (results.Length == 0) return null;
else return results[0]; } protected abstract
DomainObject CreateDomainObject();
class CricketerMapper...
protected override DomainObject CreateDomainObject() {
return new Cricketer();
}
Фактическая загрузка объекта из базы данных осуществляется посредством несколь-
ких методов загрузки: по одному на каждый класс преобразователя и на все его супер-
классы.
class CricketerMapper...
protected override void Load(DomainObject obj,
'bDataRow row) {
Глава 12. Объектно-реляционные типовые решения... 319
base.Load(obj,row);
Cricketer cricketer = (Cricketer) obj;
cricketer.battingAverage = (double)row[
V'battingAverage"]; }
class AbstractPlayerMapper...
protected override void Load(DomainObject obj,
"^DataRow row) {
base.Load(obj, row); Player player =
(Player) obj; player.name =
(String)row["name"]; }
class Mapper...
protected virtual void Load(DomainObject obj,
4c>DataRow row) {
obj.Id = (int) row ["id"];
}
Данная логика описывает выполнение поиска с использованием преобразователя для
конкретного класса. Вместо этого можно воспользоваться преобразователем для супер-
класса, а именно объектом playerMapper, который позволяет найти объект, в какой бы
из таблиц тот ни находился. Поскольку все данные уже загружены в оперативную память
(объект DataSet), можно поступить так, как показано ниже.
class PlayerMapper...
public Player Find (long key) (
Player result;
result = fmapper.Find(key) ;
if (result != null) return result;
result = bmapper.Find(key) ;
if (result != null) return result;
result = cmapper.Find(key) ;
if (result != null) return result;
return null; }
Запомните: это можно делать только потому, что данные уже хранятся в оперативной
памяти. Если бы для доступа к данным нам пришлось совершить три обращения к базе
данных (или даже больше, в зависимости от количества производных классов), приве-
денный метод оказался бы крайне медленным. В этом случае могу порекомендовать вы-
полнить соединение всех таблиц конкретных классов, что позволит извлечь нужные све-
дения за одно обращение к базе данных. К сожалению, большие соединения медленны
сами по себе, поэтому придется провести несколько "черновых" тестирований, чтобы
понять, что хорошо, а что плохо для вашего приложения. Кроме того, это будет внешнее
соединение, которое помимо низкой скорости работы обладает весьма непонятным и
непереносимым синтаксисом.
320 Часть II. Типовые решения
Обновление объекта
Метод обновления может быть описан в суперклассе Mapper.
class Mapper...
public virtual void Update (DomainObject arg) {
Save (arg, FindRow(arg.Id)); }
Для обновления, как и для загрузки, используется группа методов сохранения (по од-
ному на каждый класс преобразователя).
class CricketerMapper...
protected override void Save(DomainObject obj,
^DataRow row) {
base.Save(obj, row);
Cricketer cricketer = (Cricketer) obj;
row["battingAverage"] = cricketer.battingAverage; }
class AbstractPlayerMapper...
protected override void Save(DomainObject obj,
DataRow row) {
Player player = (Player) obj;
row["name"] = player.name; }
Объект piayerMapper выбирает нужный конкретный преобразователь и делегирует
ему выполнение обновления.
class PiayerMapper...
public override void Update (DomainObject obj) {
MapperFor(obj).Update(obj);
}
private Mapper MapperFor(DomainObject obj) { if
(obj is Footballer)
return fmapper; if
(obj is Bowler) return
bmapper; if (obj is
Cricketer)
return cmapper;
throw new Exception("No mapper available");
}
Вставка объекта
Операцию вставки можно рассматривать как разновидность обновления. Дополни-
тельное поведение заключается в создании новой строки и может быть реализовано в су-
перклассе.
Глава 12. Объектно-реляционные типовые решения... 321
class Mapper...
public virtual long Insert (DomainObject arg) {
DataRow row = table.NewRow();
arg. Id = GetNextlDO ;
row["id"] = arg.Id;
Save (arg, row);
table.Rows.Add(row);
return arg.Id; }
И здесь класс PlayerMapper делегирует выполнение вставки нужному преобразователю.
class PlayerMapper...
public override long Insert (DomainObject obj) {
return MapperFor(obj).Insert(obj); }
Удаление объекта
Схема удаления совсем проста. Как и раньше, у нас есть метод, определенный в су-
перклассе.
class Mapper...
public virtual void Delete(DomainObject obj) {
DataRow row = FindRow(obj.Id);
row.Delete();
}
Есть также метод класса PlayerMapper, делегирующий выполнение удаления кон-
кретному преобразователю.
class PlayerMapper...
public override void Delete (DomainObject obj) {
MapperFor(obj) .Delete (obj); }
322 Часть II. Типовые решения
Преобразователи наследования (Inheritance Mappers)
Структура, предназначенная для организации преобразователей,
которые работают с иерархиями наследования
При отображении объектно-ориентированной иерархии наследования на реляцион-
ную базу данных крайне важно минимизировать количество кода, необходимого для за-
грузки и сохранения содержимого базы данных. Кроме того, необходимо реализовать и
абстрактное, и конкретное поведение, что позволит сохранять или загружать как экземп-
ляр суперкласса, так и экземпляры производных классов.
Глава 12. Объектно-реляционные типовые решения... 323
Хотя детали поведения могут различаться в зависимости от выбранной схемы отобра-
жения (наследование с одной таблицей (Single Table Inheritance, 297), наследование с таб-
лицами для каждого класса (Class Table Inheritance, 305) и наследование с таблицами для
каждого конкретного класса (Concrete Table Inheritance, 313)), общая структура остается
одной и той же.
Принцип действия
Преобразователи можно организовать в иерархию, так, чтобы у каждого класса доме-
на был свой преобразователь, который будет загружать и сохранять данные этого класса.
В этом случае у нас есть одна точка, в которой можно изменить принцип отображения.
Данный подход хорошо применять для конкретных преобразователей, которые "знают",
как отображать конкретные объекты иерархии. Тем не менее иногда преобразователи
нужны и для абстрактных классов. Это можно реализовать с помощью специальных пре-
образователей, которые находятся за пределами базовой иерархии, однако делегируют
выполнение операций соответствующим конкретным преобразователям.
Чтобы попроще объяснить принцип действия преобразователей наследования, я начну
с конкретных преобразователей. В нашей модели есть конкретные преобразователи для
Объектов Footballer (футболист), Cricketer (игрок В крикет) И Bowler (игрок В бо-
улинг). Базовое поведение этих преобразователей включает в себя методы поиска, встав-
ки, обновления и удаления.
Методы поиска объявлены в конкретных производных классах, поскольку они долж-
ны возвращать экземпляр конкретного класса. Другими словами, метод класса Bowler-
Mapper должен возвращать не абстрактный объект, а объект Bowler (игрок в боулинг).
Большинство объектно-ориентированных языков программирования не позволяют из-
менять объявленный тип метода, поэтому невозможно наследовать метод поиска от абст-
рактного класса и одновременно присвоить этому методу конкретный тип. Разумеется,
можно возвращать абстрактный объект, однако это вынудит пользователя класса выпол-
нять обратное приведение объекта к нужному типу, чего следует всячески избегать.
(Данная проблема не возникает в языках с возможностью динамической типизации.)
Основное поведение метода поиска заключается в том, чтобы найти заданную строку
базы данных, создать экземпляр объекта корректного типа (это определяется производ-
ным классом) и загрузить в новый объект найденные данные. Метод загрузки реализован
в каждом преобразователе иерархии, выполняющем загрузку данных для соответствую-
щего класса. Это значит, что метод загрузки класса BowlerMapper загружает данные,
специфичные для класса Bowler, после чего вызывает метод суперкласса, чтобы тот за-
грузил данные, специфичные для класса Cricketer. Упомянутый суперкласс вызывает
метод своего суперкласса и т.д.
Методы обновления и вставки выполняются по одной и той же схеме с использовани-
ем метода сохранения. В данном случае интерфейс этих методов можно определить в су-
перклассе, а точнее, в супертипе слоя (Layer Supertype, 491). Метод вставки создает новую
строку и затем сохраняет в ней данные объекта домена, используя для этого методы со-
хранения. Метод обновления просто сохраняет данные, используя для этого все те же ме-
тоды сохранения. Последние выполняются аналогично методам загрузки: каждый класс
сохраняет специфические для него данные и вызывает метод своего суперкласса.
Данная схема значительно упрощает написание преобразователей для сохранения
информации об определенной части иерархии. Следующим шагом является реализация