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

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

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

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

дексатором.

class PersonGateway...

public DataRow this [long key ] {

get {

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

Table.Select (filter) [0]; } } public override DataTable

Table {

get {return Data.Tables [TableName];}

}

Обновление данных происходит с помощью метода Update объекта DataSetHolder.

class DataSetHolder...

public void Update() {

foreach (String table in DataAdapters.Keys)

((OleDbDataAdapter)DataAdapters[table]).Update(

4>Data, table); ) public DataTable this[String tableName]

{

get {return Data.Tables[tableName];} }

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

объект DataSet, вставить в таблицу новую строку и заполнить каждое поле новой запи-

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

class PersonGateway.. .

public long Insert(String lastName, String firstname,

'bint numberOfDependents) {

long key = PersonGatewayDS().GetNextID();

DataRow newRow = Table.NewRow(); newRow

["id"] = key; newRow ["lastName"] =

lastName; newRow ["firstName"] =

firstname;

newRow ["numberOfDependents"] = numberOfDependents;

Table.Rows.Add(newRow); return key; }

Глава 10. Архитектурные типовые решения источников данных 175

Шлюз записи данных (Row Data Gateway)

Объект, выполняющий роль шлюза (Gateway, 483) к отдельной записи

источника данных. Каждой строке таблицы базы данных

соответствует свой экземпляр шлюза записи данных

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

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

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

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

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

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

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

шие (но крайне досадные!) расхождения в реализации SQL

Типовое решение шлюз записи данных предоставляет в ваше распоряжение объекты,

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

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

доступа к источнику данных скрыты за интерфейсом.

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

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

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

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

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

преобразования весьма просты. Рассматриваемое типовое решение содержит все данные

о строке, поэтому клиент имеет возможность непосредственного доступа к шлюзу записи

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

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

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

При реализации шлюза записи данных возникает вопрос: куда "пристроить" методы

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

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

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

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

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

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

этого поиска (рис. Ю.2).

Иногда шлюз записи данных трудно отличить от активной записи (Active Record, 182).

В этом случае следует обратить внимание на наличие какой-либо логики домена; если

она есть, значит, это активная запись. Реализация шлюза записи данных должна включать

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

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

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

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

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

Кроме того, если с одними и теми же таблицами работают два шлюза записи данных, об-

новление второго шлюза может аннулировать обновление первого. Универсального спо-

соба предотвратить эту проблему не существует; разработчикам просто необходимо сле-

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

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

реализовать методы обновления.

Шлюзы записи данных довольно трудоемки в написании. Тем не менее генерацию их

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

данных (Metadata Mapping, 325). В этом случае весь код, описывающий доступ к базе

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

Назначение

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

двух вещах: следует ли вообще использовать шлюз, и если да, то какой именно — шлюз

записи данных или шлюз таблицы данных (Table Data Gateway, 167).

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

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

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

Я не использую шлюз записи данных с моделью предметной области (Domain Model, 140).

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

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

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

Mapper, 187). Последний лучше справляется с отделением структуры данных от объектов

домена, потому что объектам домена не нужно знать о структуре базы данных. Конечно же,

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

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

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

ления данных: одно в бизнес-логике, одно в шлюзе записи данных и еще одно в базе данных.

Для крупномасштабных систем это слишком много. Поэтому я обычно использую шлюзы

записи данных, отражающие структуру базы данных.

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

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

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

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

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

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

а второй создается вручную.

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

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

бы реализовать в шлюзе записи данных. Перенос этой логики в шлюз записи данных

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

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

Пример: запись о сотруднике (Java)

Ниже приведен пример реализации шлюза записи данных для простой таблицы со-

трудников под именем people.

create table people (ID int primary key, lastname varchar,

'bfirstname varchar, number_of_dependents int)

У данной таблицы есть шлюз PersonGateway. Код этого класса начинается с описа-

ний полей данных и функций доступа (accessors).

class PersonGateway...

private String lastName; private

String firstName; private int

numberOfDependents; public String

getLastName() {

return lastName; } public void

setLastName(String lastName) {

this.lastName = lastName; }

public String getFirstName() {

return firstName; } public void

setFirstName(String firstName) {

this.firstName = firstName; }

public int getNumberOfDependents() {

return numberOfDependents; } public void

setNumberOfDependents(int numberOfDependents) {

this.numberOfDependents = numberOfDependents;

}

Класс шлюза включает в себя собственные методы обновления и вставки данных

Хранение идентификаторов следует поручить супертипу слоя (Layer Supertype, 491) шлюзов записи

данных.

Глава 10. Архитектурные типовые решения источников данных 179

class PersonGateway...

private static final String updateStatementString =

"UPDATE people " +

" set lastname = ?, firstname = ?,

number_of_dependents = ? " +

" where id = ?";

public void update () {

PreparedStatement updateStatement = null;

try {

updateStatement = DB.prepare (updateStatementString);

updateStatement.setString(1, lastName);

updateStatement.setString(2, firstName);

updateStatement.setlnt(3, numberOfDependents) ;

updateStatement.setlnt(4, getlDO .intValue());

updateStatement.execute() ;

} catch (Exception e) {

throw new ApplicationException(e) ; } finally

{DB.cleanup(updateStatement); } } private static

final String insertStatementString =

"INSERT INTO people VALUES (?,?,?,?)";

public Long insert() {

PreparedStatement insertStatement = null;

try {

insertStatement = DB.prepare(insertStatementString);

setID(findNextDatabaseId());

insertStatement.setlnt (1, getlDO .intValue());

insertStatement.setString(2, lastName);

insertStatement.setString(3, firstName) ;

insertStatement.setlnt (4, numberOfDependents);

insertStatement.execute() ;

Registry.addPerson(this) ;

return get ID(); } catch

(SQLException e) {

throw new ApplicationException (e); }

finally {DB.cleanup(insertStatement); } }

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

Класс PersonFinder. Он ИСПОЛЬЗуеТСЯ В сочетании С классом PersonGateway ДЛЯ СОЗДа-

ния новых объектов шлюза.

class PersonFinder...

private final static String findStatementString =

"SELECT id, lastname, firstname,

number_of_dependents " + "from people "

+ "WHERE id = ?"; public PersonGateway

find(Long id) {

PersonGateway result = (PersonGateway)

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

Registry.getPerson (id);

if (result != null) return result;

PreparedStatement findStatement = null;

ResultSet rs = null; try {

findStatement = DB.prepare(findStatementString);

findstatement.setLong(1, id.longValue() ) ; rs =

findStatement.executeQuery(); rs.next();

result = PersonGateway.load(rs) ;

return result; } catch (SQLException

e) {

throw new ApplicationException(e) ; }

finally {DB.cleanUp(findStatement,rs) ; ) }

public PersonGateway find(long id) {

return find(new Long(id)); }

class PersonGateway...

public static PersonGateway load(ResultSet rs)

throws SQLException {

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

PersonGateway result = (PersonGateway)

Registry.getPerson(id);

if (result != null) return result;

String lastNameArg = rs.getString (2);

String firstNameArg = rs.getString (3);

int numDependentsArg = rs.getlnt(4);

result = new PersonGateway(id, lastNameArg,

firstNameArg, numDependentsArg) ;

Registry.addPerson(result) ;

return result;

Для извлечения данных о нескольких сотрудниках на основе заданного критерия

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

class PersonFinder...

private static final String findResponsibleStatement =

"SELECT id, lastname, firstname,

number_of_dependents " + "from people "+

"WHERE number_of_dependents > 0";

public List findResponsibles() { List

result = new ArrayListO;

PreparedStatement stmt = null; ResultSet

rs = null; try {

stmt = DB.prepare(findResponsibleStatement); rs

= stmt.executeQuery();

Глава 10. Архитектурные типовые решения источников данных 181

while (rs.nextO) {

result.add(PersonGateway.load(rs)); }

return result; } catch

(SQLException e) {

throw new ApplicationException(e); }

finally {DB.cleanup(stmt,rs); } }

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

(Identity Map, 216).

Теперь мы можем применить шлюзы в сценарии транзакции.

PersonFinder finder = new PersonFinder();

Iterator people = finder.findResponsibles().iterator();

StringBuffer result = new StringBuffer();

while (people.hasNext()) {

PersonGateway each = (PersonGateway) people.next();

result.append(each.getLastName());

result.append("");

result.append(each.getFirstName());

result.append("");

result.append(String.valueOf(

each.getNumberOfDependents() ) ) ;

result.append("\n"); }

return result.toString();

Пример: использование диспетчера данных для объекта домена (Java)

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

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

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

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

class Person...

private PersonGateway data; public

Person(PersonGateway data) {

this.data = data;

}

Теперь функции доступа логики домена могут обращаться к шлюзу за необходимыми

данными.

class Person...

public int getNumberOfDependents() {

return data.getNumberOfDependents();

}

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

Логика домена использует get-методы для извлечения данных из шлюза.

class Person...

public Money getExemption() {

Money baseExemption = Money.dollars(1500); Money

dependentExemption = Money.dollars(750); return

baseExemption.add(dependentExemption.multiply(

4>this.getNumberOfDependents() ) ) ;

Активная запись (Active Record)

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

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

и добавляет к данным логику домена

Этот объект охватывает и данные и поведение. Большая часть его данных является

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

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

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

как их записывать в нее.

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

В основе типового решения активная запись лежит модель предметной области (Domain

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

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

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

приложения. Впрочем, иногда некоторые фрагменты логики домена содержатся в сцена-

риях транзакции (Transaction Script, 133), а общие элементы кода, ориентированные на

работу с данными, — в активной записи.

Глава 10. Архитектурные типовые решения источников данных 183

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

лице базы данных: каждое поле объекта должно соответствовать одному столбцу табли-

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

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

необходимости вы можете применить отображение внешних ключей (Foreign Key

Mapping, 258), однако это не обязательно. Активная запись может применяться к табли-

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

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

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

ченные для выполнения следующих операций:

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

выполнения SQL-запроса;

• создание нового экземпляра активной записи для последующей вставки в таблицу;

• статические методы поиска, выполняющие стандартные SQL-запросы и возвра

щающие активные записи;

• обновление базы данных и вставка в нее данных из активной записи;

• извлечение и установка значений полей (get- и set-методы);

• реализация некоторых фрагментов бизнес-логики.

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

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

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

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

ло определено поле идентификации (Identity Field, 237).

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

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

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

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

Активная запись очень похожа на шлюз записи данных (Row Data Gateway, 175). Прин-

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

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

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

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

рировать ее все-таки не следует.

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

в этом типовом решении статические методы поиска. Однако я не вижу смысла вьшелять

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

нужно, да и тестировать будет легче).

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

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