design-patterns - 我的代码去哪里了？ Controller 、服务还是模型？

Question

因此我们有一个 PHP+Zend Framework+Doctrine 1.2 应用程序，其结构如下:

Controller -> 操作 -> 服务 -> 模型

并非所有模型都通过服务进行交互。我们目前的观点是 Controller 可以直接使用模型，服务也可以使用其他服务。

我的问题是:如果您有一段业务逻辑，您使用什么准则来确定实现该逻辑的代码是否应该位于模型层、 Controller 层或服务层？我对 Controller 层和服务层之间的区别特别感兴趣。

以下是我们的开发团队提出的指南，但我对有关它们的任何反馈/意见非常感兴趣:

1. 服务和 Controller 包含 绑定(bind)各种组件的逻辑 共同完成一项任务。 这个逻辑可能不存在于 模型以避免依赖性并使得 模型更可重用。 这 逻辑也可能不在模型中 因为我们认为模型应该 避免消耗过多的东西 要避免的应用程序堆栈 不必要的依赖项(例如: 模型不会消耗服务或 Controller )。
2. 当可以使用代码时，使用服务而不是 Controller 通过多个模块或 Controller 。
3. 模型应包含尽可能多的逻辑，但应避免 引用特定应用程序 功能。通常是模特 至少包含验证逻辑。
4. 对于任何功能，请考虑将其放入模型中 第一的。如果有一个令人信服的 不这样做的理由，考虑一项服务 (还要考虑开销和 维持新服务的目的)。 如果不需要某项服务并且 代码不会在此重复使用 应用程序使用 Controller 。

Answer 1

我认为您应该将业务逻辑放在服务层内。其背后的原因是业务逻辑应该与数据结构/模型分开关注。

与大多数情况一样，您经常会发现数据结构和业务逻辑紧密相连，因此可能没有足够的分离来证明我的第一个陈述的合理性。然而，我认为这通常指向代码气味。

在每个实例优化中，您会将代码移动到性能最佳的位置，但在第一次迭代中，我仍然会将其放置在服务层中。

我同意模型应该包含尽可能多的内向逻辑，但模型必须是非特定的。业务逻辑是一个使用应用程序模型的用例，因此应该分开。