CakePHP：将“服务”逻辑放在哪里答案

【问题标题】：CakePHP: Where to put 'Services' logicCakePHP：将“服务”逻辑放在哪里
【发布时间】：2013-07-26 21:04:56
【问题描述】：

我来自 Java/Grails 背景，似乎无法在线找到关于 CakePHP 应用程序的服务逻辑应该存储在哪里的明确答案。通过“服务”，我指的是通常通过依赖注入实例化以在域对象上执行业务逻辑的类。他们应该能够查询任何域对象并做出更改以响应控制器操作。

目前，CakePHP 的“组件”类似乎最接近这种行为。我可以将组件加载到任何控制器中并根据需要执行其方法。但是，我在几个地方读到过组件永远不应该访问数据库，这样做会导致性能急剧下降。

我还研究了 CakePHP 的“行为”类，它似乎根本不符合要求。将域对象组织到数据结构设置中似乎装备精良，但这不是服务将执行的那种逻辑。此外，要将任何模型定义导入行为，我必须编辑模型定义本身以允许访问，这非常尴尬。

所以我问这个问题：服务逻辑应该存储在哪里？当然不是控制器，因为它应该只包含处理请求和发送响应的最小逻辑。

【问题讨论】：

这里有一个免费的提示：远离 CakePHP。它是 PHP 中最糟糕的框架之一，它绝对没有像 MVC 那样远程实现任何东西。如果想使用至少能识别“服务”概念的东西，你可以试试 Symfony2。
参数 1：全局状态。 CakePHP 基本上基于单例和其他静态范围参数的使用。
论据 2：静态类：大部分 CakePHP 核心由静态方法组成。这使得所有代码都与特定的类名称紧密耦合，最终被用作命名空间。
@tereško 我没有删除它猜它是一些版主。我同意1和2，也不喜欢。我不同意 3，它可能不是 MVC，但它的工作方式很好。我个人喜欢愚蠢的模板。 4 部分正确，5 对于 2.0 不正确。而且我已经尝试自己对 CakePHP 进行一些更改，但老实说，让事情发生变化是一件很痛苦的事情，更多的讨论而不是一天结束时的生产力。所以我放弃了，寄希望于 3.0。
因为其他人可以来这里看到这些 cmets，我只是想给新手一个提示。我认为这里的所有论点都可以通过 CakePHP 3.X 版本解决。我们的团队发现它非常易于维护，并且在必要时可以轻松调整不同类型的架构。

标签： php cakephp model-view-controller service dependency-injection

【解决方案1】：

所以我问这个问题：服务逻辑应该存储在哪里？当然不是控制器，因为它应该只包含最小的处理请求并发送响应的逻辑。

听起来像是Dispatcher Filter 的理想用例。它甚至在控制器被实例化之前就被调用了。如果您需要查询数据库，只需通过 ClassRegistry::init('YourModelName') 加载模型并将请求参数传递给模型方法并在请求中返回您需要的任何内容。根本不需要控制器。我们已经使用 Dispatcher Filters 实现了 oauth + xhttp，而无需调用任何控制器。

在组件中使用模型应该如何影响性能...我不知道是谁提出了这个奇怪的想法，听起来不是你找到的最好的文章。确实不应该将模型层相关的逻辑放入其中，但是您可以通过控制器实例和控制器模型来调用模型。

【讨论】：

“服务逻辑”主要代表存储抽象和领域实体之间的交互。你的回答与此无关。 Hell .. cake 甚至没有将模型层的两个方面分开，因为它在其AppModel 类中使用了 activerecord。
@burzum 经过一番阅读，在我看来，DispatcherFilter 对 API 调用等功能非常有用。然而，我的大部分逻辑本质上是更广泛的。例如，当我收到一个身份验证失败的 POST 请求时，我需要将失败的登录尝试记录到数据库中。虽然是一个简单的概念，但存在相当多的代码来实例化新记录、验证和持久化它。这种计算不属于控制器，因为它与请求或响应没有直接关系。对于这样的任务，你还会推荐 DispatcherFilter 吗？
Dispatcher Filters 对中间件逻辑有好处，但组件更适合他所描述的内容

【解决方案2】：

组件是 CakePHP 中的服务层。它们由依赖注入容器（组件集合）构建，并传递给要处理的控制器、请求和响应。

除了保持层之间的分离之外，组件可以做什么没有任何限制。可以直接从组件中使用数据库连接或模型并修改请求。

如果您只让它们针对特定情况起作用，那么组件实际上是非常轻量级的。检查动作名称是限制组件范围的常用方法。您还可以注入设置，以便它知道何时可以执行自定义服务逻辑。

【讨论】：