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

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

Описание. Если предметная область несложная, то логично возложить на каждый класс порцию бизнес-логики. При использовании этого паттерна объект класса «осведомлен» о том, как взаимодействовать с таблицами базы данных.

Единица работы (Unit Of Work)

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

Решение. Создается специальный объект, «отслеживающий» изменения, вносимые в базу данных. Данное типовое решение позволяет проконтролировать, какие объекты считываются и какие модифицируются, и обслужить операции обновления содержимого базы данных.

Преимущества. Нет необходимости явно вызывать методы сохранения, достаточно сообщить объекту Единица работы о необходимости фиксации (commit) результатов в базе данных. Вся сложная логика фиксации сосредоточена в одном месте, таким образом, координируется запись в базу данных.

Загрузка по требованию (Lazy Load)

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

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

Коллекция объектов (Identity Мар)

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

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

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

Множество записей (Record Set)

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

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

Наследование с одной таблицей (Single Table Inheritance)

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

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

Игрок

Пример структуры игроков в разных Рис. 80. Пример наследова-

Рис. 79. Пример структуры игроков в разных Рис. 80. Пример наследова-

видах спорта ния с одной таблицей

(таблица)

имя

клуб

число голов тип

При использовании паттерна Наследование с одной таблицей формируется следующая таблица (рис. 80).

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

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

Наследование с таблицами для каждого класса (Class Table Inheritance)

Описание. Каждой таблице соответствует отдельный класс. Данное отображение является самым простым и прямолинейным вариантом организации наследования (связи между классами и таблицами). При использовании паттерна «Наследование с таблицами для каждого класса» (для примера паттерна «Наследование с одной таблицей») формируются две таблицы (рис. 81).

Футболист (таблица)

Хоккеист (таблица)

имя

имя

клуб

число голов

Рис. 81. Наследование с таблицами для каждого класса

Недостатки. Для загрузки информации об отдельном объекте приходится осуществлять несколько операций соединения Coin), что обычно снижает производительность системы.

Оптимистическая автономная блокировка

(Optimistic Offline Lock)

Задача. Бизнес-транзакция содержит несколько системных транзакций, в этом случае СУБД не может гарантировать согласованность записей базы данных. Любая попытка доступа нескольких сеансов к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.

Решение. Провести проверку, не вступят ли изменения, проведенные одним сеансом, в конфликт с изменениями, проведенными другим сеансом (например, сверяется номер версии отдельной записи, сохраненной вместе с состоянием сеанса, с текущим номером версии этой же записи в базе данных). Если проверка прошла успешно, то изменяемые записи блокируются и изменения фиксируются в базе данных. Проверка и фиксация осуществляются в рамках одной системной транзакции, данные останутся согласованными. Срок действия «Оптимистической автономной блокировки» ограничивается той системной транзакцией, в процессе которой она была установлена.

Отображение с помощью внешних ключей

Описание. Требуется организовать в реляционной базе данных отображение связи «один-ко-многим» (в отличие от базы данных для объекта легко реализовать многозначный атрибут — достаточно просто сделать коллекцией значение данного аттрибута).

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

Отображение с помощью таблицы ассоциаций

(Association Table Mapping)

Описание. Требуется организовать в реляционной базе данных отображение связи «многие-ко-многим».

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

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

Пессимистическая автономная блокировка

(Pessimistic Offline Lock)

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

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

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

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

Поле идентификации

(Identity Field)

Описание. Связи объектов и таблиц реализуются по-разному. Объекты манипулируют связями, отображая ссылки в виде адресов памяти. В реляционных базах данных связь одной таблицы с другой задается путем формирования соответствующего внешнего ключа. Кроме того, объект способен сохранить множество ссылок с помощью коллекции, в то время как правила нормализации таблиц базы данных допускают применение только однозначных ссылок. Требуется организовать отображение связей.

Решение. Сохранять в составе объекта идентификаторы связанных с ним объектов-записей и обращаться к этим значениям, когда требуется прямое и обратное отображение объектов и ключей таблиц базы данных.

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

Преобразователь данных

(Data Mapper)

Описание. При переходе от полей «Шлюза таблицы данных» к полям объектов «Модели предметной области» приходится выполнять определенные преобразования, которые приводят к усложнению объектов домена.

Решение. Изолировать «Модель предметной области» от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение объектов домена в таблицы базы данных. Преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес-логикой, и позволяет независимо модернизировать как «Модель предметной области», так и схему базы данных.

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

Сохранение сеанса на стороне клиента

(Client Session State)

Задача. Сохранить сведения о сеансе.

Решение. Данные о состоянии сеанса можно сохранять на стороне клиента. При этом клиент передает серверу все сведения о сеансе вместе с каждым запросом. Никаких данных о состоянии сеанса на сервере не хранится. Если есть необходимость хранения числового идентификатора сеанса, то альтернативы данному паттерну не существует.

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

Недостатки. Возникают проблемы безопасности при передаче данных от клиента серверу — передаваемые данные приходится шифровать. Затруднительно использовать данный паттерн при большом объеме информации о сеансе. Часто возникает проблема преобразования формата данных.

Сохранение сеанса на стороне сервера

(Server Session State)

Задача. Сохранять сведения о сеансе.

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

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

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

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

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

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

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

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

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

 
< Пред   СОДЕРЖАНИЕ     След >