PHP OOP: слой бизнес-логики-слой БД

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

6
design design-patterns oop php

2 ответов

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

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

2

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

Архитектурные Шаблоны Источников Данных:

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

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

Логические Шаблоны Домена:

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

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

9