Фаулер М. Архитектура корпоративных программных приложений
Подождите немного. Документ загружается.
304 Часть II. Типовые решения
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;
}
class PlayerMapper...
public override long Insert (DomainObject obj) {
return MapperFor(obj).Insert(obj);
}
Удаление объекта
Удалить объект очень просто. Операции удаления определены на абстрактном уровне,
а также в классе-оболочке PlayerMapper.
class Mapper...
public virtual void Delete(DomainObject obj) {
DataRow row = FindRow(obj.Id);
row.Delete();
}
class PlayerMapper...
public override void Delete (DomainObject obj) {
MapperFor(obj).Delete(obj); }
Глава 12. Объектно-реляционные типовые решения... 305
Наследование с таблицами для каждого класса (Class Table Inheritance)
Представляет иерархию наследования классов, используя по одной
таблице для каждого класса
Одним из наиболее очевидных несоответствий объектной и реляционной моделей яв-
ляется то, что реляционные базы данных не поддерживают наследование. Между тем
требуется создать такую структуру базы данных, которая бы хорошо отображалась на
объекты и сохраняла все возможные связи объектной модели. Для этого применяется ти-
повое решение наследование с таблицами для каждого класса, которое использует по од-
ной таблице на каждый класс структуры наследования.
Принцип действия
Идея наследования с таблицами для каждого класса проста и понятна: каждому классу
модели предметной области соответствует своя таблица базы данных. Поля класса домена
отображаются непосредственно на столбцы соответствующей таблицы. Как и в других
схемах отображения иерархии наследования, в данном типовом решении применяется
фундаментальный принцип преобразователей наследования (Inheritance Mappers, 322).
При использовании наследования с таблицами для каждого класса возникает вопрос,
как связать соответствующие строки таблиц базы данных. Возможным решением может
стать использование общего значения первичного ключа: например, чтобы строка с клю-
чом 101 в таблице футболистов и строка с ключом 101 в таблице игроков соответствовали
одному и тому же объекту домена. Поскольку таблица суперкласса содержит по одной
строке на каждую строку каждой таблицы производных классов, первичные ключи запи-
сей должны быть уникальными в пределах всех таблиц производных классов. Вместо
306 Часть II. Типовые решения
этого у каждой таблицы может быть собственный первичный ключ. В этом случае для
привязки соответствующих строк в таблицу суперкласса добавляются внешние ключи
таблиц производных классов.
Еще одна важная проблема реализации наследования с таблицами для каждого класса
— эффективное извлечение данных из множества таблиц. Очевидно, выполнение
отдельного запроса к каждой таблице не будет эффективным, поскольку потребует мно-
жества обращений к базе данных. Эту проблему можно решить путем соединения нес-
кольких таблиц. Следует, однако, учесть, что в силу способа оптимизации, применяемого
в большинстве баз данных, соединение трех или более таблиц будет обрабатываться
крайне медленно.
И наконец, нельзя не обратить внимание на такой аспект: при выполнении запросов
не всегда известно, к каким именно таблицам следует применить соединение. Если вы
ищете сведения о футболисте, то, естественно, обратитесь к таблице футболистов; если
же потребуются сведения о группе игроков, к каким таблицам обратиться? Разумеется, не
все таблицы будут содержать необходимые данные. Для выполнения эффективных со-
единений с такими таблицами применяется внешнее соединение, однако оно нестан-
дартно и достаточно медленно. В качестве альтернативы можно предложить следующее
решение: вначале считать корневую таблицу, а затем использовать код типа класса, что-
бы определить, какие таблицы следует считывать далее. К сожалению, этот способ требу-
ет выполнения нескольких запросов.
Назначение
Типовые решения наследование с таблицами для каждого класса, наследование с одной
таблицей (Single Table Inheritance, 305) и наследование с таблицами для каждого конкрет-
ного класса (Concrete Table Inheritance, 313) применяются для отображения иерархии на-
следования на реляционную базу данных.
Наследование с таблицами для каждого класса имеет ряд преимуществ.
• Все поля таблицы соответствуют содержимому каждой ее строки (т.е. есть в каж
дом описываемом объекте), поэтому таблицы легки в понимании и не занимают
лишнего места.
• Взаимосвязь между моделью домена и схемой базы данных проста и понятна.
Однако это типовое решение имеет и слабые стороны.
• Загрузка объекта охватывает сразу несколько таблиц, что требует их соединения
либо множества обращений к базе данных с последующим "сшиванием" результа
тов в памяти.
• Перемещение полей в производный класс или суперкласс требует изменения
структуры базы данных.
• Таблицы суперклассов могут стать "узким местом" в вопросах производительно
сти, поскольку доступ к таким таблицам будет осуществляться слишком часто.
• Высокая степень нормализации может стать препятствием для выполнения запро
сов, не хранящихся в базе данных (ad hoc queries).
Глава 12. Объектно-реляционные типовые решения... 307
Напомню: вы вовсе не обязаны использовать единственную форму отображения для
всей иерархии наследования. Например, вы можете применить наследование с таблицами
для каждого класса для классов, находящихся на верхних уровнях иерархии, и несколько
наследований с таблицами для каждого конкретного класса для классов на более низких
уровнях.
Дополнительные источники информации
В литературе по программным продуктам и технологиям IBM данное типовое реше-
ние фигурирует под именем отображение "корень-лист" (Root-Leaf Mapping) [9].
Пример: семейство игроков (С#)
Рассмотрим реализацию модели, приведенной в начале раздела. И вновь я восполь-
зуюсь уже знакомым (хотя и несколько странным) примером с игроками, а также стан-
дартным принципом преобразователей наследования (рис. 12.9).
Каждый класс должен определить таблицу, которая будет содержать в себе его данные
и тип кода.
class AbstractPlayerMapper.. .
abstract public String TypeCode {get;} protected
static String TABLENAME = "Players";
class FootballerMapper...
public override String TypeCode {
get (return "F";}
}
protected new static String
TABLENAME = "Footballers";
Обратите внимание, что в данном примере (в отличие от других) не переопределяется
имя таблицы. Это сделано потому, что у каждого класса должна быть своя таблица, даже
если его экземпляр будет являться экземпляром производного класса.
Загрузка объекта
Если вы уже просматривали другие примеры отображений иерархии наследования, то
наверняка помните, что выполнение поиска инициируется методом конкретного преоб-
разователя.
class FootballerMapper...
public Footballer Find(long id) {
return (Footballer) AbstractFind (id, TABLENAME); }
308 Часть II. Типовые решения
Рис. 12.9. Универсальная схема классов для преобразователей наследования
Метод AbstractFind ищет строку с заданным значением ключа. В случае успеха
данный метод создает объект домена, после чего вызывает метод загрузки этого объекта.
class Mapper...
public DomainObject AbstractFind(long id,
^String tablename) {
DataRow row = FindRow (id, tableFor(tablename)); if
(row == null) return null; else {
DomainObject result = CreateDomainObject();
result.Id = id; Load(result); return result;
Глава 12. Объектно-реляционные типовые решения... 309
protected DataTable tableFor(String name) {
return Gateway.Data.Tables[name];
}
protected DataRow FindRow(long id, DataTable table) {
String filter = String.Format("id = {0}", id);
DataRow[] results = table.Select(filter);
return (results.Length == 0) ? null : results[0];
}
protected DataRow FindRow (long id, String tablename) {
return FindRow(id, tableFor(tablename));
}
protected abstract DomainObject CreateDomainObject();
class FootballerMapper...
protected override DomainObject CreateDomainObject(){
return new Footballer(); }
У каждого класса есть свой метод загрузки, который загружает свойства, определен-
ные в этом классе.
class FootballerMapper...
protected override void Load(DomainObject obj) {
base.Load(obj);
DataRow row = FindRow (obj.Id, tableFor(TABLENAME));
Footballer footballer = (Footballer) obj;
footballer.club = (String)row["club"]; }
class AbstractPlayerMapper...
protected override void Load(DomainObject obj) {
DataRow row = FindRow (obj.Id, tableFor(TABLENAME));
Player player = (Player) obj; player.name =
(String)row["name"];
}
Как и в других примерах (хотя здесь это, пожалуй, более очевидно), я исхожу из
предположения, что данные были загружены в объект ADO.NET DataSet и кэширо-
ваны в оперативной памяти. Это позволяет выполнить несколько обращений к таблич-
ным данным без особых потерь в производительности. Если же вы обращаетесь непо-
средственно к базе данных, нагрузку придется уменьшить. В этом примере для умень-
шения нагрузки можно создать соединение всех таблиц и в дальнейшем ставить свои
запросы именно к нему.
Объект piayerMapper определяет, какому типу принадлежит искомый игрок, и затем
делегирует выполнение поиска нужному конкретному преобразователю.
class PiayerMapper. . .
public Player Find (long key) {
DataRow row = FindRow(key, tableFor(TABLENAME));
310 Часть!!. Типовые решения
if (row == null) return null;
else {
String typecode = (String) row["type"];
if (typecode == bmapper.TypeCode)
return bmapper.Find(key); if
(typecode == cmapper.TypeCode)
return cmapper.Find(key); if
(typecode == fmapper.TypeCode)
return fmapper.Find(key); throw new
Exception("unknown type"); } } protected static
String TABLENAME = "Players";
Обновление объекта
Метод обновления определен в суперклассе Mapper.
class Mapper...
public virtual void Update (DomainObject arg){
Save (arg);
}
Он реализован посредством группы методов сохранения— по одному на каждый
класс иерархии.
class FootballerMapper...
protected override void Save(DomainObject obj) {
base.Save(obj);
DataRow row = FindRow (obj.Id, tableFor(TABLENAME));
Footballer footballer = (Footballer) obj;
row["club"] = footballer.club; }
class AbstractPlayerMapper...
protected override void Save(DomainObject obj) {
DataRow row = FindRow (obj.Id, tableFor(TABLENAME));
Player player = (Player) obj;
row["name"] = player.name;
row["type"] = TypeCode;
}
Метод обновления класса piayerMapper переопределяет универсальный метод, что-
бы делегировать выполнение обновления нужному конкретному преобразователю.
class PiayerMapper...
public override void Update (DomainObject obj) {
MapperFor(obj).Update(obj);
Глава 12. Объектно-реляционные типовые решения... 311
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"); }
Вставка объекта
Метод вставки объявлен в суперклассе Mapper. Выполнение вставки происходит в два
этапа: вначале создаются новые строки базы данных, а затем с помощью методов обнов-
ления в созданные строки помещаются необходимые данные.
class Mapper.. .
public virtual long Insert (DomainObject obj) {
obj . Id = GetNextlDO ;
AddRow(obj);
Save(obj) ;
return obj.Id;
}
Каждый класс, задействованный во вставке объекта, добавляет в свою таблицу новую
строку.
class FootballerMapper...
protected override void AddRow (DomainObject obj) {
base.AddRow(obj);
InsertRow (obj, tableFor(TABLENAME)); }
class AbstractPlayerMapper...
protected override void AddRow (DomainObject obj) {
InsertRow (obj, tableFor(TABLENAME)); }
class Mapper...
abstract protected void AddRow (DomainObject obj);
protected virtual void InsertRow (DomainObject arg,
4>DataTable table) {
DataRow row = table.NewRow();
row["id"] = arg.Id;
table.Rows.Add(row);
312 Часть II. Типовые решения
Объект PI a yerMappe r делегирует полномочия нужному конкретному преобразователю.
class PlayerMapper...
public override long Insert (DomainObject obj) {
return MapperFor (obj) .Insert(obj);
}
Удаление объекта
Чтобы удалить объект, каждый класс удаляет из своей таблицы соответствующую
строку.
class FootballerMapper...
public override void Delete(DomainObject obj) {
base.Delete(obj);
DataRow row = FindRow(obj.Id, TABLENAME);
row.Delete();
}
class AbstractPlayerMapper...
public override void Delete(DomainObject obj) {
DataRow row = FindRow(obj.Id, tableFor(TABLENAME));
row.Delete();
}
class Mapper...
public abstract void Delete(DomainObject obj);
И снова объект PlayerMapper перекладывает всю работу на конкретный преобразо-
ватель.
class PlayerMapper...
override public void Delete(DomainObject obj) {
MapperFor (obj) .Delete(obj);
Глава 12. Объектно-реляционные типовые решения... 313
Наследование с таблицами для каждого конкретного класса
(Concrete Table Inheritance)
Представляет иерархию наследования классов, используя по одной
таблице для каждого конкретного класса этой иерархии
Спросите любого пуриста объектно-ориентированного подхода, и он с негодованием
подтвердит, что реляционные базы данных не поддерживают наследование, — факт, ко-
торый значительно затрудняет объектно-реляционное отображение. Если рассматривать
таблицы с "точки зрения" экземпляров объектов, наиболее естественным будет отобра-
зить каждый объект, находящийся в оперативной памяти, на отдельную строку базы дан-
ных. Этот подход реализован в типовом решении наследование с таблицами для каждого
конкретного класса, которое подразумевает создание отдельной таблицы для каждого
конкретного класса иерархии наследования.
Должен признаться, что при выборе названия для данного типового решения у меня
возникли некоторые затруднения. Большинство разработчиков рассматривают его как
основанное на использовании "листьев", поскольку в большинстве случаев таблицы ба-
зы данных соответствуют листьям иерархии объектов. Если следовать этой логике, дан-
ное типовое решение нужно было бы назвать, например, "наследование с таблицами для
каждого листа" (leaf table inheritance). На самом деле во многих источниках и правда ис-
пользуют слово "лист" (leaf). Тем не менее иногда таблицы создаются и для конкретных
классов, не являющихся листьями, поэтому с формальной точки зрения мое название
более корректно (хотя и не совсем интуитивно).