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

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

Puc. 9.8. Схема связей EJB-класса RecognitionService

Глава 9. Представление бизнес-логики 165

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

операции посредством типового решения наблюдатель (Observer), представленного в [20].

Конечно, это более эффектное решение, однако реализовать его в многопоточном, не

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

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

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

рые предпочли бы реализовать ее в методах объектов домена, таких, как Con-

tract. calculateRevenueRecognitions (), ИЛИ вообще В слое источника данных, ЧТО

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

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

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

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

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

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

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

вания приложения. Во-вторых, инкапсуляция логики приложения на более высоком

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

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

Слой служб как типовое решение для организации слоя логики корпоративного при-

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

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

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

POJO или компонентов сеанса либо сочетание их обоих. Кроме того, слой служб может

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

зависимости от способа реализации, и это наиболее важно, данное типовое решение

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

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

Глава 10

Архитектурные типовые

решения источников

данных

Шлюз таблицы данных (Table Data Gateway)

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

Использование SQL в логике приложений может быть связано с некоторыми пробле-

мами. Не все разработчики владеют языком SQL или хорошо в нем разбираются. В свою

очередь, администраторы СУБД должны иметь удобный доступ к командам SQL для на-

стройки и расширения своих баз данных.

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

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

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

действия с базой данных.

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

Интерфейс шлюза таблицы данных чрезвычайно прост. Обычно он включает в себя

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

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

ответствующей команды SQL и выполняет ее в контексте установленного соединения с

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

лишь передает данные в таблицу и из таблицы.

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

Пожалуй, наиболее интересная особенность шлюза таблицы данных — это то, как он

возвращает результат выполнения запроса. Даже простой запрос типа "найти данные с

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

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

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

значение.

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

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

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

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

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

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

мистов, ссылающихся на содержимое коллекции. Более удачным решением является ис-

пользование универсального объекта переноса данных (Data Transfer Object, 419).

Вместо всего перечисленного результат выполнения SQL-запроса может быть воз-

вращен в виде множества записей (Record Set, 523). Вообще говоря, это не совсем кор-

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

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

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

Тем не менее этот способ весьма эффективен во многих средах разработки, широко ис-

пользующих множество записей, например в таких, как .NET. В этом случае шлюз табли-

цы данных хорошо сочетается с модулем таблицы (Table Module, 148). Если все обновле-

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

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

кода от базы данных.

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

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

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

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

дания таких зависимостей не слишком усложняет дело, однако мне это все равно не нра-

вится.

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

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

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

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

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

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

обновлять данные и поэтому не будет обладать соответствующими методами. Тем не ме-

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

тодах типового решения шлюз таблицы данных — прекрасный выбор.

Назначение

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

записи данных (Row Data Gateway, 175), необходимо подумать о том, следует ли вообще

обращаться к шлюзу и если да, то к какому именно.

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

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

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

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

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

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

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

мощью преобразователя данных (Data Mapper, 187).

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

цы. Методы шлюза таблицы данных возвращают структуры данных в виде множеств запи-

сей, с которыми затем работает модуль таблицы. На самом деле другой подход отображе-

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

мне так кажется).

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

зования в сценариях транзакции (Transaction Script, 133). В действительности выбор од-

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

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

посредством объекта переноса данных, однако мне это решение кажется более трудоем-

ким (если только этот объект уже не был реализован где-нибудь в другом месте вашего

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

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

закции.

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

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

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

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

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

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

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

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

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

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

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

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

фактическую структуру используемой таблицы.

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

В [3] рассматривается аналог шлюза таблицы данных под именем объект доступа к дан-

ным (Data Access Object). В нем результаты выполнения запросов возвращаются в виде

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

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

книге, применимы как к шлюзу таблицы данных, так и к шлюзу записи данных.

В моей книге это типовое решение получило другое имя — шлюз таблицы данных. Во-

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

концепцией шлюза. Кроме того, термин объект доступа к данным (Data Access Object) и

его аббревиатура DAO уже давно применяются компанией Microsoft для обозначения

собственной технологии.

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

Пример: класс PersonGateway (C#)

Типовое решение шлюз таблицы данных — это стандартная технология доступа к ба-

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

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

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

использует всех преимуществ объектов DataSet библиотеки ADO.NET; вместо этого

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

сороподобного интерфейса (объекты DataReader). Концепция потокового режима

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

обходимости помещать их в оперативную память.

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

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

полнения SQL-команды SELECT В виде объекта ADO.NET DataReader, который пре-

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

class PersonGateway...

public IDataReader FindAllO {

String sql = "select * from person"; return new

OleDbCommand(sql, DB.Connection).ExecuteReader(); } public

IDataReader FindWithLastName(String lastName) {

String sql = "SELECT * FROM person WHERE lastname = ?";

IDbCommand comm = new OleDbCommand(sql, DB.Connection);

coram.Parameters.Add (new OleDbParameter("lastname", lastName));

return comm.ExecuteReader(); } public IDataReader

FindWhere(String whereClause) {

String sql = String.Format("select * from

person where {0}", whereClause);

return new OleDbCommand(sql,

DB.Connection).ExecuteReader();

В большинстве случаев будем извлекать группу строк посредством объекта Da-

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

чего применяется метод, показанный ниже.

class PersonGateway...

public Object [] FindRow (long key) {

String sql = "SELECT * FROM person WHERE id = ?";

IDbCommand comm = new OleDbCommand(sql, DB.Connection);

comm.Parameters.Add(new OleDbParameter("key", key));

IDataReader reader = comm.ExecuteReader(); reader.Read();

Object [] result = new Object [reader.FieldCount];

reader.GetValues(result) ; reader.Close();

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

return result;

}

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

вают соответствующие команды SQL.

class PersonGateway...

public void Update (long key, String lastname, String

firstname, long numberOfDependents) { String sql = @" UPDATE

person

SET lastname = ?, firstname = ?,

numberOfDependents = ?

WHERE id = ?";

IDbCommand comm = new OleDbCommand(sql, DB.Connection) ;;

comm.Parameters.Add(new OleDbParameter ("last", lastname));

comm.Parameters.Add(new OleDbParameter ("first",

firstname));

comm.Parameters.Add(new OleDbParameter ("numDep",

numberOfDependents));

comm.Parameters.Add(new OleDbParameter ("key", key));

comm.ExecuteNonQuery (); }

class PersonGateway...

public long Insert(String lastName, String firstName,

long numberOfDependents) {

String sql = "INSERT INTO person VALUES (?,?,?,?)";

long key = GetNextID ();

IDbCommand comm = new OleDbCommand(sql, DB.Connection);

comm.Parameters.Add(new OleDbParameter ("key", key));

comm.Parameters.Add(new OleDbParameter ("last",

lastName));

comm.Parameters.Add(new OleDbParameter ("first",

firstName));

comm.Parameters.Add(new OleDbParameter ("numDep",

numberOfDependents));

comm.ExecuteNonQuery();

return key;

)

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

class PersonGateway...

public void Delete (long key) {

String sql = "DELETE FROM person WHERE id = ?";

IDbCommand comm =new OleDbCommand(sql, DB.Connection);

comm.Parameters.Add(new OleDbParameter ("key", key));

comm.ExecuteNonQuery();

}

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

Пример: использование объектов ADO.NET DataSet (C#)

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

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

SQL Для доступа к базам данных в среде .NET чаще используются объекты DataSet,

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

форме).

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

taAdapter. Мне показалось удобным создать для объектов DataSet и DataAdapter не-

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

(рис. 10.1). Большинство предлагаемых ниже методов универсальны и могут быть реали-

зованы в суперклассе.

Объект DataSetHolder индексирует объекты DataSet И DataAdapter ПО именам

таблиц.

class DataSetHolder...

public DataSet Data = new DataSet();

private Hashtable DataAdapters = new HashtableO;

Рис. 10.1. Схема классов для шлюза таблицы данных, ориентированного на доступ к данным с помощью

объектов DataSet и вспомогательного объекта DataSetHolder

Шлюз сохраняет объект DataSetHolder и предоставляет доступ к содержимому со-

ответствующего объекта DataSet своим клиентам.

class DataGateway...

public DataSetHolder Holder;

public DataSet Data {

get {return Holder.Data;}

}

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

Шлюз может работать с существующим объектом DataSetHolder или же создать новый.

class DataGateway...

protected DataSetGateway() {

Holder =new DataSetHolder(); } protected

DataSetGateway(DataSetHolder holder) {

this.Holder = holder; }

В данном примере поиск записей выполняется немного иначе. Объект DataSet пред-

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

данные нескольких таблиц. Поэтому данные лучше загрузить в объект DataSet.

class DataGateway...

public void LoadAll() {

String commandString = String.Format(

"select * from {0}", TableName);

Holder.FillData(commandString, TableName); }

public void LoadWhere(String whereClause) {

String commandString = String.Format ("select * from {0}

where (1)", TableName, whereClause);

Holder.FillData(commandString, TableName); }

abstract public String TableName {get;}

class PersonGateway. . .

public override String TableName {

get (return "Person";}

}

class DataSetHolder...

public void FillData(String query, String tableName) {

if (DataAdapters.Contains(tableName)) throw new

MutlipleLoadException() ;

OleDbDataAdapter da = new OleDbDataAdapter(query,

DB.Connection) ;

OleDbCommandBuilder builder = new

OleDbCommandBuilder(da);

da.Fill(Data, tableName);

DataAdapters.Add(tableName, da) ; }

Обновление данных осуществляется путем выполнения соответствующих операций

над объектом DataSet непосредственно в клиентском коде.

person.LoadAll();

person [key ] ["lastname"] = "Odell";

person.Holder.Update() ;