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

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

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

result.append("?"); }

return result.toString ();

Извлечение множества объектов

Существует несколько способов извлечь множество объектов посредством одного за-

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

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

оператор WHERE.

class Mapper...

public Set findObjectsWhere (String whereClause) {

String sql = "SELECT" + dataMap.columnList() + " FROM " +

dataMap.getTableName() + " WHERE " + whereClause;

PreparedStatement stmt = null; ResultSet rs = null; Set

result = new HashSetO; try {

stmt = DB.prepare(sql); rs =

stmt.executeQuery(); result =

loadAll(rs); } catch

(Exception e) {

throw new ApplicationException (e);

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

return result;

}

public Set loadAll(ResultSet rs) throws SQLException,

InstantiationException, IllegalAccessException { Set

result = new HashSetO; while (rs.nextO) {

DomainObject newObj = (DomainObject)

dataMap.getDomainClass().newlnstance() ;

newObj = load (rs); result.add(newObj); }

return result;

}

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

преобразователей.

class PersonMapper...

public Set findLastNamesLike (String pattern) {

String sql =

"SELECT" + dataMap.columnList () +

" FROM " + dataMap.getTableName () +

" WHERE UPPER(lastName) like UPPER(?)";

PreparedStatement stmt = null; ResultSet rs =

null;

Глава 13. Типовые решения объектно-реляционного отображения... 335

try {

stmt = DB.prepare(sql);

stmt.setString (1, pattern);

rs = stmt.executeQuery ();

return loadAll (rs);

} catch (Exception e) {throw new ApplicationException (e); }

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

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

том запроса (Query Object, 335).

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

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

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

сочтете нужным.

Объект запроса (Query Object)

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

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

знают. Кроме того, для формирования запросов, необходимо иметь четкое представление

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

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

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

регламентированных запросов (ad hoc queries). Кроме того, при изменении схемы базы

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

выражениях.

О&ьект запроса— это разновидность типового решения интерпретатор (Interpreter)

[20], т.е. структура объектов, формирующих SQL-запрос. Чтобы создать такой запрос,

достаточно сослаться на имена классов и полей, а не на имена таблиц и столбцов. В этом

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

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

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

ном месте.

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

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

татор, предназначенная для представления SQL-запросов. Основная функция объекта

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

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

вующие SQL-выражения.

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

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

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

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

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

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

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

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

потребностей.

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

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

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

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

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

объект запроса должен "знать", как структура базы данных отображается на объектную

модель, что, несомненно, требует применения отображения метаданных (Metadata

Mapping, 325).

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

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

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

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

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

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

ченными для моделирования различных схем баз данных.

Менее очевидное применение объекта запроса — это уменьшение количества запро-

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

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

извлечь нужные сведения из коллекции объектов (Identity Map, 216) и таким образом из-

бежать дополнительного обращения к базе данных. Более утонченный подход предпола-

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

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

ражение, присоединенное с помощью оператора AND.

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

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

ми объектно-реляционного отображения.

Глава 13. Типовые решения объектно-реляционного отображения... 337

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

земпляром объекта домена. Например, вы можете создать экземпляр объекта Person

("сотрудник"), атрибут которого lastName ("фамилия") будет иметь значение Fowler, a

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

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

всех сотрудниках с фамилией Fowler. Данный метод весьма прост и удобен в примене-

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

Назначение

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

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

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

ласти (Domain Model, 140) и преобразователь данных (Data Mapper, 187); при этом, чтобы

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

Объекты запроса не нужны и тогда, когда разработчики хорошо знают SQfc-B этом

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

тодах поиска.

Настоящие преимущества объектов запроса раскрываются при наличии более слож-

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

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

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

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

щаться к коммерческим средствам. Что касается меня, то я тоже отдаю предпочтение го-

товым продуктам.

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

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

сложностей реализации. Главное — максимально урезать функциональность объекта за-

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

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

Пример объекта запроса можно найти в разделе книги [2], посвященном обсуждению

разновидностей типового решения интерпретатор. Кроме того, объект запроса тесно свя-

зан с типовым решением спецификация (Specification), описанным в [14, 15].

Пример: простой объект запроса (Java)

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

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

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

данных на основе набора критериев, соединенных оператором AND (В математике это на-

зывается конъюнкцией элементарных предикатов).

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

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

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

вариантам SQL-оператора WHERE.

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

class QueryObject...

private Class klass;

private List criteria = new ArrayList();

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

значением с помощью указанного SQL-оператора.

class Criteria...

private String sqlOperator;

protected String field;

protected Object value;

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

методов.

class Criteria...

public static Criteria greaterThan(String fieldName,

int value) {

return Criteria.greaterThan(fieldName, new

Integer(value) ); }

public static Criteria greaterThan(String fieldName,

Object value) {

return new Criteria(" > ", fieldName, value);

}

private Criteria(String sql, String field, Object value) {

this.sqlOperator = sql; this.field = field; this.value =

value; }

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

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

class Criteria...

QueryObject query = new QueryObject(Person.class);

query.addCriteria(Criteria.greaterThan(

"numberOfDependents", 0) ) ;

Предположим, у меня есть следующий объект Person:

class Person...

private String lastName; private

String firstName; private int

numberOfDependents;

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

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

критерия.

Глава 13. Типовые решения объектно-реляционного отображения... 339

QueryObject query = new QueryObject (Person.class);

query.addCriteria(Criteria.greaterThan(

"numberOfDependents", 0) ) ;

Этого достаточно, чтобы описать запрос. Теперь объект запроса должен преобразовать

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

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

поиск объектов по заданному SQL-выражению WHERE.

class QueryObject...

public Set execute(UnitOfWork uow) {

this.uow = uow;

return uow.getMapper(klass).findObjectsWhere(

generateWhereClause()); }

class Mapper...

public Set findObjectsWhere (String whereClause) {

String sql = "SELECT" + dataMap.columnList() + " FROM " +

dataMap.getTableName() +" WHERE " + whereClause;

PreparedStatement stmt = null; ResultSet rs = null; Set result

= new HashSetO; try {

stmt = DB.prepare(sql);

rs = stmt.executeQuery();

result = loadAll(rs); }

catch (Exception e) {

throw new ApplicationException (e); }

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

return result;

}

В этом примере я использую единицу работы (Unit of Work, 205), которая содержит

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

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

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

Для генерации SQL-выражения WHERE объект запроса последовательно просматривает

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

class QueryObject...

private String generateWhereClause() {

StringBuffer result = new StringBuffer(); for (Iterator it =

criteria.iterator(); it.hasNext();) { Criteria с =

(Criteria)it.next (); if (result.length()!= 0)

result.append(" AND ");

result.append(c.generateSql(

uow.getMapper(klass).getDataMap()));

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

}

return result.toString() ; }

class Criteria...

public String generateSql(DataMap dataMap) {

return dataMap.getColumnForField(field) +

sqlOperator + value; }

class DataMap...

public String getColumnForField (String fieldName) {

for (Iterator it = getColumns(); it.hasNext();) {

ColumnMap columnMap = (ColumnMap)it.next(); if

(columnMap.getFieldName().equals(fieldName))

return columnMap.getColumnName();

}

throw new ApplicationException ("Unable to find

column for " + fieldName); }

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

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

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

никах, чьи фамилии начинаются на букву "F". Мы можем сформировать объект запроса

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

QueryObject query = new QueryObject(Person.class) ;

query.addCriteria(Criteria.greaterThan(

"numberOfDependents", 0) ) ;

query.addCriteria(Criteria.matches("lastName", "f%"));

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

сложные выражения WHERE.

class Criteria...

public static Criteria matches(String fieldName,

String pattern) {

return new MatchCriteria(fieldName, pattern); }

class MatchCriteria extends Criteria...

public String generateSql(DataMap dataMap) {

return "UPPER(" + dataMap.getColumnForField(field) + ")

LIKE UPPER ('" + value + "')"; }

Глава 13. Типовые решения объектно-реляционного отображения... 341

Хранилище (Repository)

Эдвард Хайвт и Роберт Ми

Выступает в роли посредника между слоем домена и слоем

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

для доступа к объектам домена

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

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

данных (как, например, слой преобразователей данных (DataMapper, 187)). В подобных

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

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

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

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

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

Типовое решение хранилище располагается между слоем домена и слоем отображе-

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

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

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

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

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

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

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

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

аспект слоя хранения. Помимо этого, наличие хранилища помогает достичь полной изо-

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

данных.

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

Хранилище — достаточно сложное типовое решение, в реализации которого использу-

ется несколько других типовых решений, описанных в книге. В действительности оно

напоминает небольшой фрагмент объектно-ориентированной базы данных и этим сход-

но с объектом запроса (Query Object, 335), который чаще приобретают в составе коммер-

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

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

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

объектом запроса существенно увеличивает возможности слоя объектно-реляционного

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

Несмотря на сложные механизмы, реализованные внутри хранилища, его интерфейс

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

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

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

дый Критерий примерно следующим образом: criteria, equals (Person. LAST_NAME,

"Fowler") и criteria, like (Person. FIRST_NAME, "M"). Затем нужно вызвать метод

repository.matching (criteria), чтобы возвратить список сотрудников с фамилией

Fowler, имя которых начинается на букву "М". Для большего удобства в абстрактном

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

ного соответствия было бы неплохо воспользоваться методом наподобие sole-

Match (criteria) , который бы возвращал объект, а не коллекцию объектов. В число

других распространенных методов входит метод поиска по идентификатору byObject

id (id), который совсем несложно реализовать, используя метод soleMatch.

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

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

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

Разумеется, клиентский код должен быть осведомлен о том, что "видимая" коллекция

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

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

pository — не самая удачная идея.

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

вателя данных, выполняя извлечение объектов на основе спецификаций [14]. Сравните

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

объект критериев (простая разновидность типового решения спецификация (Specifi-

cation)), добавляет этот критерий непосредственно к объекту запроса и выполняет запрос.

При работе с хранилищем клиентский код формирует критерии и передает их хранилищу

с просьбой возвратить объекты, которые подойдут под заданное описание. Таким обра-

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

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

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

Глава 13. Типовые решения объектно-реляционного отображения... 343

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

тельную часть мощи последнего.

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

данных (Metadata Mapping, 325) с объектом запроса, которое применяется для автомати-

ческой генерации SQL-кода на основе заданных критериев. То, какой объект будет отве-

чать за добавление критериев в объект запроса — объект критериев, объект запроса или

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

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

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

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

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

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

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

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

Хранилище может сослужить хорошую службу в улучшении читабельности и ясности

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

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

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

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

HttpRequest в объект критериев; передача критериев соответствующему хранилищу по-

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

Назначение

Использование хранилища в большой системе с множеством типов объектов домена и

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

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

шение спецификация (в наших примерах оно представлено в виде объектов критериев),

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

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

которого выполняется настройка объекта запроса (query object) для обработки частных

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

осуществлять в терминах объектов.

Несмотря на это, настоящие возможности хранилища проявляются в системах с не-

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

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

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

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

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

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

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

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

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

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

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

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

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