2015-02-04
373
Активная запись (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 код от бизнес - логики. |
| Решение | Копировать структуру таблицы базы данных в отдельном классе, который содержит методы активизации запросов, возвращающих множество записей.
|
