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

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

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

Назначение

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

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

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

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

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

рынке программного обеспечения появились расширения языка SQL, позволяющие из-

влекать XML-данные в пределах поля, однако это еще не то, что нужно (по крайней мере

подобные решения не обеспечивают переносимости).

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

ный фрагмент объектной модели в виде единого целого (в частности, объекта LOB). Для

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

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

В этом случае сохраненный граф объектов может быть описан с помощью SQL-схемы.

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

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

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

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

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

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

XPath).

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

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

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

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

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

лиц базы данных отчетов.

Пример: сериализация иерархии отделов в формат XML (Java)

В этом примере воспользуемся моделью покупателей и отделов, рассмотренной в на-

чале раздела, и сериализуем иерархию отделов в объект CLOB формата XML. На момент

написания этой книги средства Java для работы с XML были весьма примитивны и по-

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

жет измениться. (Кроме того, я использовал раннюю версию технологии JDOM.)

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

class Customer...

private String name;

private List departments = new ArrayList();

class Department...

private String name;

private List subsidiaries = new ArrayList();

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

Соответствующая база данных состоит всего из одной таблицы.

create table customers (ID int primary key, name varchar,

departments varchar)

В нашем примере объект Customer будет выполнять роль активной записи (Active

Record, 182). Рассмотрим, как выполняется вставка графа отделов в базу данных.

class Customer.. .

public Long insert О {

PreparedStatement insertStatement = null;

try {

insertStatement = DB.prepare(insertStatementString);

setID(findNextDatabaseId()) ;

insertStatement.setlnt(l, getID().intValue() ) ;

insertStatement.setString(2, name);

insertStatement.setString(3,

XmlStringer.write(departmentsToXmlElement() ) ) ;

insertStatement.execute();

Registry.addCustomer(this);

return getID(); } catch

(SQLException e) {

throw new ApplicationException(e); }

finally {DB.cleanUp(insertStatement); } }

public Element departmentsToXmlElement() {

Element root = new Element("departmentList") ;

Iterator i = departments.iterator(); while

(i.hasNext()) {

Department dep = (Department) i.next();

root.addContent (dep.toXmlElement() ) ;

}

return root;

}

class Department...

Element toXmlElement() (

Element root = new Element("department");

root.setAttribute("name", name); Iterator i

= subsidiaries.iterator(); while

(i.hasNextO ) {

Department dep = (Department) i.nextf);

root.addContent(dep.toXmlElement() ) ;

}

return root;

}

У объекта Customer есть метод для сериализации содержимого поля departments в

единую модель XML DOM (Document Object Model — объектная модель документа).

У каждого объекта Department также есть метод для сериализации соответствующего

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

отдела (с рекурсивной сериализацией "дочерних" отделов) в свою модель DOM. После

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

делов в строку (с помощью служебного класса xmistringer) и помещает ее в базу дан-

ных. Нас не очень волнует структура полученной строки. Она вполне читабельна, однако

просматривать ее слишком часто не придется.

<?xml version="l.0" encoding="UTF-8"?>

</department>

</department>

</departmentList>

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

class Customer...

public static Customer load(ResultSet rs)

throws SQLException {

Long id = new Long(rs.getLong("id"));

Customer result = (Customer) Registry.getCustomer(id);

if (result != null) return result;

String name = rs.getString("name");

String departmentLob = rs.getString("departments");

result = new Customer(name);

result.readDepartments(Xmistringer.read(departmentLob));

return result; } void

readDepartments(Element source) {

List result = new ArrayListO;

Iterator it = source.getChildren("department") .iterator ();

while (it.hasNext())

addDepartment(Department.readXml((Element) it.next()));

}

class Department...

static Department readXml(Element source) {

String name = source.getAttributeValue("name");

Department result = new Department(name);

Iterator it = source.getChildren("department").iterator();

while (it.hasNext())

result.addSubsidiary(readXml((Element) it.next () ) ) ;

return result;

}

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

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

Department содержит методдля восстановления отдела (и его дочерних отделов) из кода

XML, а объект Customer оснащен методом, позволяющим извлечь из базы данных код

XML и преобразовать полученную строку (с помощью служебного класса Xmistringer)

в список отделов.

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

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

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

вать расширенные средства для работы с XML, которые поддерживают добавление к по-

лю проверки на правильность путем применения шаблона DTD или схемы XML.

Наследование с одной таблицей (Single Table Inheritance)

Представляет иерархию наследования классов в виде одной таблицы,

столбцы которой соответствуют всем полям классов,

входящих в иерархию

Реляционные базы данных не поддерживают наследование. Выполняя отображение

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

структуру наследования. Разумеется, крайне важно минимизировать количество соеди-

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

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

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

ной и той же таблицы.

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

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

Итак, в данном случае структура наследования отображается на одну таблицу, кото-

рая содержит в себе все данные всех классов, входящих в иерархию наследования. Каж-

дому классу (а точнее, его экземпляру) соответствует одна строка таблицы; при этом поля

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

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

ния (Inheritance Mappers, 322).

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

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

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

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

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

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

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

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

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

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

данных.

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

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

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

Назначение

Типовое решение наследование с одной таблицей является одним из вариантов

отображения иерархии наследования на реляционную базу данных. В число других

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

Table Inheritance, 305) и наследование с таблицами для каждого конкретного класса

(Concrete Table Inheritance, 313).

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

• В структуру базы данных добавляется только одна таблица.

• Для извлечения данных не нужно выполнять соединение таблиц.

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

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

Несмотря на это, у данного типового решения есть и слабые стороны.

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

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

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

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

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

хорошо сжимаются пустые поля. Например, в базах данных Oracle применяется

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

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

есть свои приемы на этот счет.

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

• Полученная таблица может оказаться слишком большой, с множеством индексов

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

тельность базы данных. Во избежание этой проблемы можно создать отдельные

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

свойство, или же копии подмножеств полей, имеющих отношение к индексам.

• Все имена столбцов таблицы принадлежат единому пространству имен, поэтому

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

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

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

Запомните: вы вовсе не обязаны использовать единственную форму отображения для

всей иерархии наследования. Вполне естественно отобразить 5—10 классов с похожей

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

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

класса.

Пример: общая таблица игроков (С#)

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

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

рис. 12.8. Каждый преобразователь должен ссылаться на таблицу DataTable объекта

ADO.NET DataSet. Эта ссылка может быть реализована в общем виде в суперклассе

Mapper. Значением свойства Data класса Gateway является объект DataSet, содержи-

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

class Mapper...

protected DataTable table {

get {return Gateway.Data.Tables [TableName ];}

}

protected Gateway Gateway;

abstract protected String TableName {get;}

Поскольку таблица всего одна, ее можно определить в абстрактном классе АЬ-

stractPlayerMapper.

class AbstractPlayerMapper...

protected override String TableName {

get {return "Players";}

Рис. 12.8. Универсальная схема классов для преобразователей наследования

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

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

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

class AbstractPlayerMapper...

abstract public String TypeCode {get;}

class CricketerMapper...

public const String TYPE_CODE = "C";

public override String TypeCode { get

{return TYPE_CODE;}

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

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

Класс playerMapper содержит по одному полю на каждый из трех конкретных клас-

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

class PlayerMapper...

private BowlerMapper bmapper;

private CricketerMapper cmapper;

private FootballerMapper fmapper;

public PlayerMapper (Gateway gateway) : base (gateway) {

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...

protected DomainObject AbstractFind(long id) {

DataRow row = FindRow(id); return (row ==

null) ? null : Find(row);

}

protected DataRow FindRow(long id) {

String filter = String.Format("id = {0}", id);

DataRow[] results = table.Select(filter);

return (results.Length == 0) ? null : results [0];

}

public DomainObject Find (DataRow row) {

DomainObject result = CreateDomainObject();

Load(result, row);

return result;

}

abstract protected DomainObject CreateDomainObject();

class CricketerMapper...

protected override DomainObject CreateDomainObject() {

return new CricketerO; }

Для загрузки данных в новый объект я применяю группу методов загрузки — по од-

ному в каждом классе иерархии.

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

class CricketerMapper...

protected override void Load(DomainObject obj,

^DataRow row) {

base.Load(obj,row);

Cricketer cricketer = (Cricketer) obj;

cricketer.battingAverage = (double)row[

"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,

DataRow row) {

obj.Id = (int) row ["id"];

}

Вместо этого я могу загрузить сведения об игроке с помощью преобразователя Play-

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

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

class PlayerMapper...

public Player Find (long key) {

DataRow row = FindRow(key); if

(row == null) return null; else

{

String typecode = (String) row["type"];

switch (typecode){

case BowlerMapper.TYPE_C0DE:

return (Player) bmapper.Find(row);

case CricketerMapper.TYPE_CODE:

return (Player) cmapper.Find(row);

case FootballerMapper.TYPE_CODE:

return (Player) fmapper.Find(row);

default:

throw new Exception("unknown type"); } } }

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

Обновление объекта

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

В суперклассе 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;

row["type"] = TypeCode; }

Преобразователь 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

brnapper; if (obj is

Cricketer)

return cmapper;

throw new Exception("No mapper available"); }

Вставка объекта

Выполнение вставки аналогично обновлению; единственная существенная разница

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