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

Question

所以我们有一个 PHP+Zend Framework+Doctrine 1.2 应用程序，它具有以下结构:

Controller -> Action -> 服务 -> 模型

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

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

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

服务和 Controller 包含
绑定(bind)各种组件的逻辑
一起完成一项任务。
这个逻辑可能不在
模型以避免依赖并制作
该模型更可重用。
这
逻辑也可能不在模型中
因为我们认为模型应该
避免消耗东西
要避免的应用程序堆栈
不必要的依赖(例如:
模型不会使用服务或
Controller )。

在可能使用代码时使用服务而不是 Controller
通过多个模块或 Controller 。

模型应包含尽可能多的逻辑，但应避免
引用特定应用程序
功能。通常是一个模型
至少包含验证逻辑。

对于任何功能，请考虑将其放入模型中
第一的。如果有一个令人信服的
不这样做的理由，考虑一项服务
(还要考虑开销和
维护新服务的目的)。
如果不需要某项服务并且
代码不会被重用
应用程序使用 Controller 。

Answer 1

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

与大多数情况一样，您经常会发现数据结构和业务逻辑紧密交织在一起，因此可能没有足够的分离来证明我的第一个陈述是正确的。但是，我认为这通常指向代码异味。

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

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