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

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

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

public String Sql;

public IList SqlParams = new ArrayList();

public Mapper Mapper;

Рис. 11.6. Классы, необходимые для создания фиктивного списка. Сегодня в языке UML еще нет

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

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

Я снабдил объект ListLoader Методом Attach ().

class ListLoader...

public void Attach (DomainList list) {

list.RunLoader = new DomainList.Loader(Load); }

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

После загрузки объекта employee коллекция записей о трудовом стаже будет нахо-

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

пустит загрузчик. В этом случае загрузчик выполнит SQL-запрос и заполнит список не-

обходимыми данными.

class ListLoader...

public void Load (DomainList list) {

list.IsLoaded = true;

IDbCommand comm = new OleDbCommand(Sql, DB.connection);

foreach (Object param in SqlParams)

comm.Parameters.Add(new OleDbParameter(

4>param.ToString(), param));

IDataReader reader = comm.ExecuteReader();

while (reader.Read()) {

DomainObject obj = GhostForLine(reader);

Mapper.LoadLine(reader, obj);

list.Add(obj);

}

reader.Close();

}

private DomainObject GhostForLine(IDataReader reader) {

return Mapper.AbstractFind((System.Int32)

dreader[Mapper.KeyColumnName] ) ; }

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

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

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

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

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

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

Глава 12

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

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

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

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

структуры

Поле идентификации (Identity Field)

Сохраняет идентификатор записи базы данных для поддержки

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

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

Выбор ключа

Первой и наиболее важной проблемой в реализации поля идентификации является

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

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

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

щенных созданию баз данных. Тем не менее необходимость отображать записи данных

на объекты наталкивает на определенные размышления.

Первое, о чем следует задуматься при выборе ключа, — это какие ключи использовать:

значащие или незначащие. Значащий ключ (meaningful key) — это нечто наподобие номера

социального страхования или идентификационного кода, т.е. данные, несущие в себе опре-

деленный смысл. Незначащий ключ (meaningless key)— это случайное число, предназ-

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

какого смысла в обычной жизни. Как ни странно, на практике выбор значащих ключей не

всегда удачен. Чтобы действительно стать ключами, они должны быть уникальными; чтобы

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

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

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

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

ошибку). Разумеется, СУБД должна среагировать на нарушение уникальности, однако это

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

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

циального страхования). Итак, значащим ключам доверять нельзя. Они могут подойти для

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

чаев рекомендую отдавать предпочтение незначащим ключам.

Следующий спорный момент — это выбор между простыми и составными ключами.

Простой ключ (simple key) состоит из одного поля базы данных, а составной (compound) —

из нескольких. Составной ключ удобно использовать в ситуациях, когда одна таблица

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

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

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

заказе. Несмотря на то что составные ключи несут в себе больше смысла, простые ключи

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

их можно обрабатывать посредством общих, абстрактных фрагментов кода. Использова-

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

сах. (Разумеется, эта проблема успешно решается автоматической генерацией кода.)

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

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

и особенно за неизменяемостью ключевых полей.

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

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

такого типа, для которого эта операция выполняется быстро. Еще одна распространен-

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

ключа идеально подходят значения типа long integer. Можно использовать и строко-

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

а вычисление следующего ключа окажется немного сложнее. Скорее всего, решающее

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

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

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

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

ностью. Особенно это касается дат, которые часто измеряются с точностью до различных

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

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

Используемые ключи могут быть уникальны по отношению к таблице или по отно-

шению ко всей базе данных. Значения ключа, уникального в пределах таблицы (table-unique

key), должны быть уникальны для каждой строки текущей таблицы (обязательное усло-

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

В свою очередь, значения ключа, уникального в пределах базы данных (database-unique key),

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

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

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

того, это позволяет применять общую коллекцию объектов (Identity Map, 216). Не беспо-

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

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

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

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

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

64-битовые ключи (что далеко не редкость), это вряд ли понадобится.

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

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

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

класса (Class Table Inheritance, 305), лучше выбирать ключи, уникальные в пределах всей

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

лицы" даже тогда, когда формально это будет означать нечто наподобие "уникальный в

пределах графа наследования".

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

дексам. В большинстве случаев это зависит от используемой СУБД и/или количества

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

формы ключей, рекомендую выполнить "черновую" проверку.

Представление поля идентификации в объекте

Самая простая форма поля идентификации — это поле, тип которого соответствует ти-

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

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

С составными ключами дело обстоит несколько сложнее. В этом случае рекомендую

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

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

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

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

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

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

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

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

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

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

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

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

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

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

рен, стоит ли так делать. Использование "явного" подхода приводит к появлению мно-

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

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

шают пользователи, когда помещают элементы ключа в неправильном порядке, однако

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

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

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

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

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

метод способен крайне запутать ситуацию.

Вычисление нового значения ключа

Каждому новому объекту нужен ключ. Теоретически это просто, однако на практике

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

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

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

Unique Identifier — GUID) или же сгенерировать ключ самому.

Наиболее простой способ — автоматическая генерация значения ключа с помощью

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

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

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

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

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

ное отображение.

Самый распространенный принцип автоматической генерации ключа — объявить

одно автоматически генерируемое поле (auto-generated field), которому при вставке новой

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

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

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

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

качестве внешнего ключа пунктов заказов. Более того, это значение должно быть извест-

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

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

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

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

Альтернативный способ автоматической генерации ключа — использование счетчика

базы данных (database counter), который применяется в Oracle. В этом случае для вычисле-

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

ку на некоторую последовательность. СУБД выполняет запрос и возвращает результи-

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

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

чать несколько значений ключа одновременно. Запрос на вычисление значения ключа

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

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

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

красно подходит для наших нужд, однако это нестандартное решение, а кроме того, оно

реализовано далеко не во всех базах данных.

Глобальный уникальный идентификатор (Globally Unique Identifier — GUID) представля-

ет собой число, сгенерированное на некотором компьютере, которое гарантированно

является уникальным во все времена для всех компьютеров мира. Многие платформы

предоставляют интерфейсы API для генерации глобальных уникальных идентифика-

торов. Для вычисления нового идентификатора применяется чрезвычайно интересный

алгоритм, который использует МАС-адрес Ethernet-карты, текущее время в наносекун-

дах, идентификатор чипсета и, возможно, точное количество волосков на вашей левой

руке (шутка). Умелое сочетание этих величин приводит к появлению действительно

уникального (и поэтому безопасного) номера. Единственным недостатком глобального

уникального идентификатора является его размер (а он, разумеется, очень большой). За-

частую возникают ситуации, когда пользователю нужно ввести значение ключа в поле

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

вато массой опечаток. Кроме того, использование ключей такого большого размера может

привести к резкому падению производительности (особенно это касается индексов).

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

сгенерировать самому. В небольших системах это можно сделать следующим образом: с

помощью SQL-функции МАХ () определить максимальное значение ключа текущей таб-

лицы и затем увеличить полученное значение на единицу. К сожалению, подобный за-

прос блокирует доступ ко всей таблице на время выполнения вставки. Это не составит

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

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

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

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

ключа.

Гораздо более удачным решением является применение таблицы ключей (key table).

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

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

лица ключей будет содержать всего лишь одну строку. Если же ключи уникальны в пре-

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

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

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

но в строку. При необходимости можно получить несколько ключей одновременно, уве-

личив значение в строке на достаточно большую величину. Это позволит сократить ко-

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

ключей.

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

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

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

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

соответствующую таблице заказов (потому что я собираюсь обновлять эту строку). Бло-

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

хочет получить значение этого же ключа, будет отказано в доступе. При использовании

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

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

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

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

любую из таблиц.

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

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

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

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

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

отдельной транзакции позволяет получить новый идентификатор сразу же после созда-

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

вершения бизнес-транзакции.

Использование таблицы ключей влияет на то, какой ключ следует выбрать — уни-

кальный в пределах таблицы или в пределах всей базы данных. Если ключи уникальны в

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

добавлении в базу данных новой таблицы. Это прибавит работы, зато параллельных об-

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

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

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

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

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

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

Напоследок отмечу еще один важный момент. Код, с помощью которого вычисляется

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

фиктивную службу (Service Stub, 519) для тестирования.

Назначение

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

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

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

области (Domain Model, 140) или шлюза записи данных (Row Data Gateway, 175). Подобное

отображение не нужно, если вы используете сценарий транзакции (Transaction Script, 133),

модуль таблицы (Table Module, 148) или шлюз таблицы данных (Table Data Gateway, 167).

Для небольшого объекта с семантикой значения (например, для объекта, представ-

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

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

(Embedded Value, 288). В то же время для сложного графа объектов, к которому не нужно

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

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

ванного объекта (Serialized LOB, 292).

В качестве альтернативы полю идентификации можно предложить расширение кол-

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

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

вать два метода поиска: объекта по ключу и ключа по объекту. Впрочем, к такому способу

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

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

Дополнительные источники информации

Несколько приемов генерации ключей рассмотрены в [28].

Пример: числовой ключ (С#)

Самая простая форма поля идентификации — это числовое поле базы данных, которое

отображается на числовое поле объекта приложения.

class DomainObject...

public const long PLACEHOLDER_ID = -1;

public long Id = PLACEHOLDER_ID;

public Boolean isNew() (return Id == PLACEHOLDER_ID;}

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

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

в .NET поля не могут иметь значение NULL. Поэтому идентификатору создаваемого объ-

екта присвоено значение-заменитель PLACEHOLDER_ID.

Наличие у объекта ключа необходимо в двух случаях: при поиске и при вставке.

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

предложении WHERE. В .NET для проведения поиска множество строк базы данных мож-

но загрузить в объект Data set и затем с помощью метода поиска выбрать из них нужную.

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();

Большая часть этого кода может быть вынесена в супертип слоя (Layer Supertype, 491).

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

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

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