我来自 Java/Grails 背景，似乎无法在网上找到关于 CakePHP 应用程序的服务逻辑应该存储在哪里的明确答案。通过“服务”，我说的是通常通过依赖注入实例化以在域对象上执行业务逻辑的类。他们应该能够查询任何域对象并响应控制器操作进行更改。
目前，CakePHP 的“组件”类似乎最接近这种行为。我可以将组件加载到任何控制器中并根据需要执行其方法。但是，我在几个地方读到过，组件永远不应该访问数据库，这样做会导致性能急剧下降。
我还研究了 CakePHP 的“行为”类，它似乎根本不适合这张票。将域对象组织到数据结构设置中似乎装备精良，但这不是服务将执行的那种逻辑。此外，要将任何模型定义导入行为，我必须编辑模型定义本身以允许访问，这非常尴尬。
所以我问这个问题：服务逻辑应该存储在哪里？当然不是控制器，因为它应该只包含处理请求和发送响应的最小逻辑。
组件是 CakePHP 中的服务层。它们由依赖注入容器（组件集合）构建，并传递给要处理的控制器、请求和响应。
除了保持层之间的分离之外，组件可以做什么没有任何限制。可以直接从组件中使用数据库连接或模型并修改请求。
如果您只让它们针对特定情况起作用，那么组件实际上是非常轻量级的。检查动作名称是限制组件范围的常用方法。您还可以注入设置，以便它可以知道何时可以执行自定义服务逻辑。
So I ask this question: Where should service logic be stored? Certainly not the controller, as it should only contain the minimal logic to process a request and send a response.
Sounds like the ideal use case for a Dispatcher Filter. It gets called even before a controller is instantiated. If you need to query the database simply load a model via ClassRegistry::init('YourModelName') and pass the request params to the model method and return whatever you need in your request. No controller needed at all. We've implemented oauth + xhttp using Dispatcher Filters without calling ever a controller.
How using a model inside a component should effect the performance... I don't know who got that strange idea, sounds like not the best article you found. It is true that you should not put model layer related logic in them but you can call a model for example through the controller instance and the controllers models.