Должна ли бизнес-логика быть отделена от модели?

Question

Должна ли бизнес-логика быть отделена от модели?

Мы работаем над довольно сложным проектом PHP5, и на прошлой неделе я работал над POC спокойного API. Мы отделяем Классы моделей от бизнес-классов.

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

Размышляя об этом, мне пришли в голову следующие вопросы:

Каков наилучший способ взаимодействия с данными, сохраняя гибкость модели и сохраняя функциональность, о которой модель в данный момент не заботится (например, отправка письма со ссылкой активации при изменении адреса электронной почты)?
Ранее я много работал с django, где большая часть бизнес-логики реализованный в модели, почему вы все равно должны разделять бизнес-логику? У вас есть какие-нибудь примеры из реальной жизни? Какие проблемы это решает, если таковые имеются?

Мне тоже пришли в голову некоторые возможные решения:

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

Каковы, на ваш взгляд, плюсы и минусы, что бы вы сделали?

3

php rest design-patterns model-view-controller

Author: hakre, 2012-07-21

Source

1 answers

score 2 · Accepted Answer

Если вы разделите свое хранилище в данных на уровне доступа к данным, вы получите желаемое разделение и функциональность в модели:

DAL (doing queries etc)
  |
Model (doing business)
  |
Controller
  |
View

Итак, в представлении у вас есть действие: Отметить как оплаченное. Таким образом, ваш контроллер получает запрос (СООБЩЕНИЕ) /счет-фактуру/1/markaspaid (или любую другую используемую вами структуру URL-адресов). Затем контроллер вызывает модель:

$Invoice=new Invoice();
$Invoice->markAsPaid(1);

Затем ваша модель вызывает DAL, чтобы фактически сохранить это изменение. Нет никакой реальной необходимости отделять это от моделей. Если это очень сложный или очень транзакционный вы можете подумать об отдельном сервисе для сложной задачи. Таким образом, ваша модель становится тоньше, а сложная часть отделяется.

Каков наилучший способ взаимодействия с данными, сохраняя гибкость модели и сохраняя функциональность, о которой модель в данный момент не заботится (например, отправка письма со ссылкой активации при изменении адреса электронной почты)?

Я не совсем понимаю это. Насколько я понимаю, ты в любом случае следует отделять процесс отправки электронной почты от обычного запуска кода. Так что поставьте его в очередь и найдите его там. Это не является частью вашего обычного пути кода. Вы можете инициировать его из своей модели, но это все.

См. Этот вопрос, в котором содержится соответствующая информация по этой теме: Задание Cakephp cron для вызова действия контроллера