CakePHP - где поставить логику обслуживания

Я программист Java, который пытается исследовать CakePHP - в настоящее время у меня проблема с структурой/дизайном приложения. Я не мог понять, где поставить основную логику приложения.

Когда я разрабатываю JavaEE, общий подход выглядит следующим образом:

  • Модели классов просты beans, которые представляют собой сущности данных (продукты, люди и т.д.) - в основном, как структуры данных с геттерами/сеттерами;

  • Классы контроллера - достаточно простые классы, которые собирают необходимые данные и вводят их в выделенный шаблон просмотра, который затем отправляется пользователю;

  • Классы DAO (DataAccessObject) или Repository - это те, которые могут загружать и хранить объекты в базе данных;

  • Сервисные классы обычно представляют собой синглеты, которые содержат определенные бизнес-логические методы - они вызывается контроллерами, другими службами или запланированными действиями, с другой стороны, они сами называют методы DAO/Repository для извлечения или изменения данных.

Например, если у меня есть сущности Person, Product и Order, когда пользователь выбирает какой-либо продукт и клики "помещают его в корзину/корзину" new Order для этого Person должны быть созданы, и это Product следует добавить к этому Order (мы можем проверить, что Person не является плохим должником и что Product присутствует в магазине и т.д.) - вся эта работа выполняется в методах OrderService, вызываемых некоторыми контроллер.

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

Теперь я немного озадачен тем, как все это делается в CakePHP. Где я должен поставить эту бизнес-логику и т.д.?

Ответы

Ответ 1

В CakePHP модельный слой состоит из коллекции активных записей, называемых AppModel. Они сочетают логику, связанную с хранением (которую вы обычно добавляете в DAO и/или хранилища) с бизнес-логикой (что обычно входит в ваши "модели" ).

Любая другая связанная с доменом логика (из вашей службы) становится частью контроллера.

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

Личное мнение
CakePHP и CodeIgniter - две из худших фреймворков в PHP.
Они заполнены плохой практикой.Суб >

Собственно, если вы делали правильный MVC, тогда слой модели будет содержать всю бизнес-логику и все, что с ней связано. Модельный слой состоит из DAO, репозиториев, Объекты домена (то, что вы называете "моделями" ) и служб.

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

Опять же, возможно, что мое понимание MVC просто неверно.

Ответ 2

Контроллеры должны содержать только логику, относящуюся ко всему, что является веб-приложением. Ваша бизнес-логика принадлежит к моделям. Я думаю, что это одна из основных ошибок, которые вы обнаружите во многих приложениях cakePHP, что большая логика помещается в контроллеры, которые фактически входят в модели.

Ответ 3

В CakePHP. "M" - это всего лишь куча моделей данных вместо моделей доменов. По моему мнению. CakePHP предназначен для разработки RAD. Это не подходит для корпоративных приложений.

Мое мнение, хотя.