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

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

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

загрузки и сохранения объекта абстрактного класса — в нашем случае это класс Player

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

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

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

ки и обновления абстрактного класса, классу playerMapper нужно переопределять эти

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

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

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

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

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

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

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

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

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

Во всех этих случаях функции класса PlayerMapper заключаются в том, чтобы опре-

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

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

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

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

Поэтому я не могу привести примеры кода для иллюстрации данного типового решения.

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

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

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

класса.

Назначение

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

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

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

вынесение содержимого класса PlayerMapper В класс AbstractPlayerMapper. Первый

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

вешь. Второй способ более реален, однако использовать общий (и довольно запутанный)

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

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

Глава 13

Типовые решения

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

отображения

с использованием

метаданных

Отображение метаданных (Metadata Mapping)

Хранит описание деталей объектно-реляционного отображения

в виде метаданных

Большая часть кода, касающегося объектно-реляционного отображения, задает соот-

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

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

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

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

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

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

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

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

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

анта: генерация кода и метод отражения.

При использовании метода генерации кода (code generation) разработчик пишет про-

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

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

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

рированным в процессе сборки (как правило, перед самым началом компиляции). Полу-

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

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

процесс сборки, какие бы сценарии в нем ни применялись. Сгенерированные классы

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

программой контроля исходного кода.

При использовании метода отражения (reflection) рефлективная программа просмат-

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

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

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

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

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

затрудняет отладку кода. Несмотря на это, метод отражения прекрасно подходит для ото-

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

ной степени ощутить гибкость метода отражения.

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

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

минимум, этой части программного обеспечения. А применение метода отражения по-

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

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

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

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

тельно упростить развертывание части приложения.

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

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

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

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

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

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

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

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

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

коду. Сгенерированный код более явный, что облегчает отслеживание действий отладчи-

ка. Поэтому я предпочитаю именно генерацию кода и думаю, что она окажется более

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

меня совсем неискушенным программистом).

В большинстве случаев метаданные хранятся в отдельном файле. В наши дни для

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

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

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

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

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

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

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

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

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

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

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

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

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

лиз осуществляются только в процессе сборки и никак не влияют на выполнение про-

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

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

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

тивной памяти.

Одним из наиболее важных моментов является сложность метаданных. Общая схема

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

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

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

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

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

трудно.

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

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

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

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

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

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

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

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

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

переопределения не существует. Все, что я могу порекомендовать, — это действовать со-

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

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

рое должно быть переопределено, в отдельный метод и затем переопределите этот метод в

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

Назначение

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

боты, необходимый для реализации отображения на базу данных. Тем не менее подго-

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

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

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

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

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

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

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

разработку.

Если вы проектируете собственную систему, попробуйте оценить преимущества и не-

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

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

использовать отражение, проверьте, как оно влияет на производительность; иногда от-

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

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

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

(Layer Supertype, 491), который будет содержать в себе все общее поведение преобразова-

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

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

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

следний происходит с использованием автоматизированных средств. Если вы измените

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

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

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

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

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

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

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

обще не получите никаких предупреждений.

С другой стороны, отображение метаданных может упростить рефакторинг базы дан-

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

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

метаданные.

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

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

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

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

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

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

Хранение метаданных

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

виде будут храниться метаданные. В нашем примере для хранения метаданных будут ис-

пользоваться два класса. Класс DataMap описывает соответствие между классом прило-

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

оно подойдет как нельзя лучше.

class DataMap...

private Class domainClass;

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

private String tableName;

private List columnMaps = new ArrayList();

Класс DataMap содержит коллекцию объектов coiumnMap, описывающих отображе-

ние столбцов таблицы на поля объекта.

class CoiumnMap...

private String columnName;

private String fieldName;

private Field field; private

DataMap dataMap;

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

ре я воспользовался стандартными отображениями типов Java. Это значит, что при ото-

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

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

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

рот.

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

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

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

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

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

ряющегося кода.

class PersonMapper...

protected void loadDataMap(){

dataMap = new DataMap (Person.class, "people");

dataMap.addColumn ("lastname", "varchar", "lastName");

dataMap.addColumn ("firstname", "varchar", "firstName");

dataMap.addColumn ("number_o Independents" , "int",

^"numberOfDependents");

}

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

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

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

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

важно для моего маленького ноутбука.

class CoiumnMap...

public CoiumnMap(String columnName, String fieldName,

4>DataMap dataMap) {

this.columnName = columnName;

this.fieldName = fieldName;

this.dataMap = dataMap;

initField();

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

private void initFieldO {

try {

field = dataMap.getDomainClass().getDeclaredField(

"^getFieldName () ) ;

field.setAccessible(true);

} catch (Exception e) {

throw new ApplicationException (

V'unable to set up field:" + fieldName, e);

}

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

данных или файла XML. Возможно, какие-то небольшие тонкости здесь все-таки есть,

однако я выношу их на ваше самостоятельное рассмотрение.

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

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

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

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

Поиск по идентификатору

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

class Mapper...

public Object findObject (Long key) {

if (uow.isLoaded(key)) return uow.getObject(key);

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

" + dataMap.getTableNarae() + " WHERE ID =?

PreparedStatement stmt = null; ResultSet rs =

null; DomainObject result = null; try {

stmt = DB.prepare(sql);

stmt.setLong(1, key.longValue ());

rs = stmt.executeQuery(); rs.next

(); result = load(rs);

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

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

return result;

}

private UnitOfWork uow;

protected DataMap dataMap;

class DataMap...

public String columnList() {

StringBuffer result = new StringBuffer (" ID"); for

(Iterator it = columnMaps.iterator(); it.hasNext();) {

result.append(",");

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

result.append(columnMap.getColumnName());

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

}

return result.toString(); )

public String getTableName(){

return tableName; }

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

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

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

ния выражения и затем кэширован, поскольку за время жизни объекта DataMap имена

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

данных используется единица работы (Unit of Work, 205).

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

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

class Mapper...

public DomainObject load(ResultSet rs)

throwsInstantiationException, IllegalAccessException,

4>SQLException {

Long key = new Long(rs.getLong("ID")); if

(uow.isLoaded(key) ) return uow.getObject(key);

DomainObject result = (DomainObject)

^dataMap.getDomainClass () .newlnstance();

result.setlD(key); uow.registerClean(result);

loadFields(rs, result); return result; }

private void loadFields(ResultSet rs, DomainObject result)

4>throws SQLException {

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

ColumnMap columnMap = (ColumnMap)it.next(); Object columnValue =

rs.getObject( 4>columnMap.getColumnName() ) ;

columnMap.setField(result, columnValue); }

}

class ColumnMap...

public void setField(Object result, Object columnValue) { try {

field.set (result, columnValue);

} catch (Exception e) { throw new ApplicationException (

V'Error in setting " + fieldName, e) ;

) )

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

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

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

поля объекта домена. Я выделил загрузку полей в отдельный метод loadFields, чтобы

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

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

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

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

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

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

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

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

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

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

class PersonMapper...

public Person find(Long key) {

return (Person) findObject(key);

}

Запись в базу данных

Все обновления выполняются с помощью одной и той же операции.

class Mapper...

public void update (DomainObject obj) {

String sql = "UPDATE " + dataMap.getTableName() +

4>dataMap.updateList() + " WHERE ID = ? PreparedStatement

stmt = null; try {

stmt = DB.prepare(sql);

int argCount = 1;

for (Iterator it = dataMap.getColumns();

^it.hasNext () ;) {

ColumnMap col = (ColumnMap) it.nextO;

stmt.setObject(argCount++, col.getValue (obj)); }

stmt.setLong(argCount, obj.getID().longValue());

stmt.executeUpdate(); } catch (SQLException e) (throw new

4>ApplicationException (e) ;

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

class DataMap...

public String updateList () {

StringBuffer result = new StringBuffer(" SET ");

for (Iterator it = columnMaps.iterator(); it.hasNext();) {

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

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

result.append(columnMap.getColumnName());

result.append(" = ?, " ) ; }

result.setLength(result.length() - 1) ;

return result.toString() ; } public Iterator

getColumns() {

return Collections.unmodifiableCollection(

^columnMaps).iterator(); }

class ColumnMap...

public Object getValue (Object subject) {

try {

return field.get (subject); }

catch (Exception e) {

throw new ApplicationException (e); } }

Вставка выполняется по той же схеме, что и обновление.

class Mapper. . .

public Long insert (DomainObject obj) {

String sql ="INSERT INTO "+ dataMap.getTableName() + V'

VALUES (?" + dataMap.insertList() + ")"; PreparedStatement

stmt = null; try {

stmt = DB.prepare(sql);

stmt.setObject(1, obj.getID());

int argCount = 2;

for (Iterator it = dataMap.getColumns();

4>it.hasNext () ;) {

ColumnMap col = (ColumnMap) it.nextO;

stmt.setObject(argCount++, col.getValue(obj) ) ; }

stmt.executeUpdate(); } catch (SQLException e)

1 throw new 4>ApplicationException (e);

} finally {DB.cleanup(stmt);

)

return obj.getID();

}

class DataMap...

public String insertList() {

StringBuffer result = new StringBuffer(); for

(int i = 0; i < columnMaps.size(); i++) {

result.append(",");