Блог

какой может быть хороший дизайн для разделения между объектами бизнес-логики и базой данных с использованием ООП?

Любой из них будет работать (из POEAA Фаулера):

Архитектурные шаблоны источников данных:

• Шлюз табличных данных: объект, который действует как шлюз к таблице базы данных. Один экземпляр обрабатывает все строки в таблице.
• Шлюз данных строки: объект, который действует как шлюз к отдельной записи в источнике данных. На строку приходится по одному экземпляру.
• Активная запись: объект, который переносит строку в таблицу базы данных или представление, инкапсулирует доступ к базе данных и добавляет логику домена к этим данным.
• Средство отображения данных: слой средств отображения, который перемещает данные между объектами и базой данных, сохраняя их независимыми друг от друга и от самого средства отображения.

Что выбрать, зависит от того, какой из них вы выбрали (тот же источник):

Шаблоны логики домена:

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

В общем, чем больше ваши бизнес-объекты напоминают схему БД и ориентированы на операции CRUD, тем проще может быть архитектура вашего источника данных и шаблон логики Doman (хотя это и не обязательно). Если вы сталкиваетесь с большим несоответствием импеданса или с большим количеством бизнес-логики, не связанной напрямую с данными БД, тогда вы можете выбрать модель домена / Data Mapper (и также можете включать ORM).

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

Таким образом, вы отделяете доступ к вашим данным от моделей вашего домена (бизнес-логики) хорошим и простым способом. Если вы немного знакомы с ООП, модель UML на странице, указанной выше, должна прояснить способ подхода и то, как она отделяет логику базы данных от бизнес-логики.