CakePHP: где поставить логику «Услуги»

Question

Я исхожу из фона Java/Grails и не могу найти однозначный ответ в Интернете о том, где должна храниться логика обслуживания для приложения CakePHP. «Службы», я говорю о классах, которые обычно создаются посредством инъекции зависимостей для ведения бизнес-логики на объектах домена. Они должны иметь возможность запрашивать любой объект домена и вносить изменения в ответ на действие контроллера.

В настоящее время CakePHP's "Component" считает себя наиболее близким к этому вопросу. Я могу загрузить компонент в любой контроллер и выполнять его методы по мере необходимости. Тем не менее, я читал в нескольких местах, что компоненты никогда не должны обращаться к базе данных, и что это приведет к некоторым крутым результатам производительности.

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

Поэтому я задаю этот вопрос: где должна храниться логика обслуживания? Конечно, не контроллер, так как он должен содержать только минимальную логику для обработки запроса и отправки ответа.

Answer 1

Компоненты - это сервисный уровень в CakePHP. Они создаются контейнером для инъекций зависимостей (Collection Collection) и передаются контроллеру, запросам и ответам, которые должны обрабатываться.

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

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

Answer 2

Поэтому я задаю этот вопрос: где должна храниться логика обслуживания? Конечно, не контроллер, так как он должен содержать только минимальную логику для обработки запроса и отправки ответа.

Звучит как идеальный вариант использования для Dispatcher Filter. Он вызывается еще до создания экземпляра контроллера. Если вам нужно запросить базу данных, просто загрузите модель через ClassRegistry :: init ('YourModelName') и передайте параметры запроса методу модели и верните все, что вам нужно в вашем запросе. Никакой контроллер не нужен вообще. Мы внедрили oauth + xhttp с помощью Dispatcher Filters без вызова контроллера.

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