Активная запись (Active Record):
Описание
| Если предметная область несложная, то логично возложить на каждый класс порцию бизнес - логики.
При использовании этого паттерна объект класса "осведомлен" о том, как взаимодействовать с таблицами базы данных.
|
Единица работы (Unit of work):
Задача
| При выполнении операций считывания или изменения объектов система должна гарантировать, что состояние базы данных останется согласованным. Например, на результат загрузки данных не должны влиять изменения, вносимые другими процессами.
|
Решение
| Создается специальный объект, "отслеживающий" изменения, вносимые в базу данных. Данное типовое решение позволяет проконтролировать, какие объекты считываются и какие модифицируются и обслужить операции обновления содержимого базы данных.
|
Преимущества
| Нет необходимости явно вызывать методы сохранения, достаточно сообщить объекту Единица работы о необходимости фиксации (commit) результатов в базе данных. Вся сложная логика фиксации сосредоточена в одном месте, таким образом, координируется запись в базу данных.
|
Загрузка по требованию (Lazy load):
Задача
| Требуется загрузить данные из базы данных в оперативную память так, чтобы при загрузке требуемого объекта автоматически загружались и другие связанные с ним объекты, при этом, объем загружаемых данных не должен быть чрезмерным.
|
Решение
| Прерывать процесс загрузки связанных объектов из базы данных, оставляя при этом соответствующую метку. Это позволит загрузить данные только тогда, когда они действительно потребуются.
|
Коллекция объектов (Indentity Map):
Задача
| Требуется гарантировать, что каждый объект будет загружен из базы данных только один раз.
|
Решение
| Создать специальную коллекцию объектов, загруженных из базы данных в пределах одной бизнес - транзакции. Таким образом, при получении запроса можно просмотреть эту коллекцию в поисках нужного объекта.
|
Преимущества
| Предотвращение повторных загрузок позволяет избежать ошибок и повышает производительность системы.
|
Множество записей (Record Set):
Описание
| Одна из основополагающих структур данных, имитирующая табличную форму представления содержимого базы данных. Как правило, Множество записей не приходится конструировать самому разработчику, поскольку, как правило, существуют стандартные классы.
|
Преимущества
| Удобно для разработчиков, поскольку предоставляет структуру данных, которая хранится в оперативной памяти и соответствует результату выполнения SQL - запроса, в то же время, эта структура данных может быть сгенерирована и использована другими частями системы.
|
Наследование с одной таблицей (Single Table Inheritance):
Задача
| Поскольку SQL не предоставляет стандартных инструментов поддержки наследования, требуется создать специальный аппарат отображения в базе данных иерархии наследования.
|
Решение
| Все поля всех классов наследования отображаются в одной и той же таблице. Например, требуется отобразить структуру
При использовании паттерна "Наследование с одной таблицей" формируется следующая таблица
|
Преимущества
| Данный метод прост в реализации и устойчив к модификациям.
|
Недостатки
| При работе пользователей с одной большой таблицей будет вводиться много блокировок.
|
Наследование с таблицами для каждого класса (Class Table Inheritance):
Описание
| Каждой таблице соответствует отдельный класс. Данное отображение является самым простым и прямолинейным вариантом организации наследования (связи между классами и таблицами). При использовании паттерна "Наследование с таблицами для каждого класса" для примера паттерна 4.2.3.7 формируются две таблицы
|
Недостатки
| Для загрузки информации об отдельном объекте приходится осуществлять несколько операций соединения (join), что обычно снижает производительность системы.
|
Оптимистическая автономная блокировка (Optimistic Offline Lock):
Задача
| Бизнес - транзакция содержит несколько системных транзакций, в этом случае СУБД не может гарантировать согласованность записей базы данных. Любая попытка доступа нескольких сеансов к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.
|
Решение
| Провести проверку, не вступят ли изменения, проведенные одним сеансом в конфликт с изменениями, проведенными другим сеансом (например, сверяется номер версии отдельной записи, сохраненной вместе с состоянием сеанса, с текущим номером версии этой же записи в базе данных). Если проверка прошла успешно, то изменяемые записи блокируются и изменения фиксируются в базе данных. Проверка и фиксация осуществляются в рамках одной системной транзакции, данные останутся согласованными. Срок действия "Оптимистической автономной блокировки" ограничивается той системной транзакцией, в процессе которого она была установлена.
|
Отображение с помощью внешних ключей:
Описание
| Требуется организовать в реляционной базе данных отображение связи "один - ко -многим" (в отличие от базы данных для объекта легко реализовать многозначный атрибут - достаточно просто сделать коллекцией значение данного аттрибута).
|
Решение
| Ссылку на коллекцию обьектов можно сохранить в базе данных путем сохранения в зависимой таблицы идентификатора главного объекта. При этом будет обеспечена возможность обновления согласованной информации в базе данных.
|
Отображение с помощью таблицы ассоциаций (Association Table Mapping):
Описание
| Требуется организовать в реляционной базе данных отображение связи "многие - ко -многим".
|
Решение
| Создать специальную таблицу отношений для хранения ассоциаций. При этом каждой паре взаимосвязанных обьектов будет соответствовать только одна строка таблицы отношений.
|
Недостатки
| Обновление данных занимает значительное время.
|
Пессимистическая автономная блокировка (Pessimistic Offline Lock):
Задача
| При использовании оптимистической блокировки один пользователь может зафиксировать результаты транзакции, а остальным пользователям будет в этом отказано. Требуется предотвратить подобный конфликт.
|
Решение
| Блокировка накладывается на данные прежде, чем бизнес - транзакция начинает с ними работать, таким образом, гарантируется завершение транзакции без негативных последствий из-за параллельных сеансов.
|
Рекомендации
| Пессимистическая блокировка должна применяться в том случае, когда велика вероятность конфликта.
|
Примечание
| Альтернативой применению "Пессимистической блокировки" может быть использование длинных системных транзакций.
|
Поле идентификации (Identity Field):
Описание
| Связи обьектов и таблиц реализуются по разному. Объекты манипулируют связями, отображая ссылки в виде адресов памяти. В реляционных базе данных связь одной таблицы с другой задается путем формирования соответствующего внешнего ключа. Кроме того, объект способен сохранить множество ссылок с помощью коллекции, в то время как правила нормализации таблиц базы данных допускают применение только однозначных ссылок. Требуется организовать отображение связей.
|
Решение
| Сохранять в составе объекта идентификаторы связанных с ним объектов - записей и обращаться к этим значениям, когда требуется прямое и обратное отображение объектов и ключей таблиц базы данных.
|
Недостатки
| Невозможно организовать ссылку на коллекцию объектов.
|
Преобразователь данных (Data Mapper):
Описание
| При переходе от полей "Шлюза таблицы данных", 4.2.3.17, к полям объектов "Модели предметной области", 4.1.3, приходится выполнять определенные преобразования, которые приводят к усложнению объектов домена.
|
Решение
| Изолировать "Модель предметной области" от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение объектов домена в таблицы базы данных. Преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес - логикой и позволяет независимо модернизировать как "Модель предметной области" так и схему базы данных.
|
Преимущества
| Полная изоляция бизнес - логики от базы данных.
|
Сохранение сеанса на стороне клиента (Client Session State):
Задача
| Сохранить сведения о сеансе
|
Решение
| Данные о состоянии сеанса можно сохранять на стороне клиента. При этом клиент передает серверу все сведения о сеансе вместе с каждым запросом. Никаких данных о состоянии сеанса на сервере не хранится. Если есть необходимость хранения числового идентификатора сеанса, то альтернативы данному паттерну не существует.
|
Преимущества
| Можно использовать серверные объекты без состояний, что обеспечивает большую степень отказоустойчивости.
|
Недостатки
| Возникают проблемы безопасности при передаче данных от клиента серверу - передаваемые данные приходится шифровать. Затруднительно использовать данный паттерн при большом объеме информации о сеансе. Часто возникает проблема преобразования формата данных.
|
Cохранение сеанса на стороне сервера (Server Session State):
Задача
| Сохранять сведения о сеансе.
|
Решение
| На клиенте хранится только идентификатор сеанса, а все данные о сеансе хранятся сервером. Для хранения обьектов сеансов на сервере формируется специальная коллекция.
|
Преимущества
| Передается только идентификатор сеанса, а не весь обьем данных о сеансе.
|
Недостатки
| Требуются значительные ресурсы сервера.
|
Шлюз записи данных (Row Data Gateway):
Задача
| Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
|
Решение
| Копировать структуру записи в отдельном классе. Для каждой записи, возвращаемой запросом к базе данных, создается экземпляр шлюза.
|
Шлюз таблицы данных (Table Data Gateway):
Задача
| Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
|
Решение
| Копировать структуру таблицы базы данных в отдельном классе, который содержит методы активизации запросов, возвращающих множество записей.
|