Архитектурные шаблоны проектирования

Архитектурные шаблоны взаимодействия с базой данных

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

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

Активная запись

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

Для этого шаблона характерны следующие характеристики:

• Экземпляр класса соответствует определенной записи в таблице.
• При создании нового экземпляра класса в таблицу добавляется новая запись.
• При чтении полей объекта считываются соответствующие значения записи таблицы баз данных.
• При изменении (удалении) какого-либо объекта изменяется (удаляется)

Единица работы

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

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

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

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

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

Количество объектов

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

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

Множество записей

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

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

Шлюз записи данных

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

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

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

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

Несоответствие понятий бизнес- и системных транзакций влечет за собой необходимость привлечения на каждом из уровней декомпозиции дополнительных объектов. Цель новых элементов – обеспечить согласованный переход к требуемому уровню представления или автоматизации бизнес-процесса.

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

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

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