Design patterns 我的代码到哪里去了？控制器、服务还是型号？

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

控制器->操作->服务->模型

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

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

以下是我们的开发团队提出的指导原则，但我对这些指导原则的任何反馈/输入都非常感兴趣：

服务和控制器包含 捆绑各种组件的逻辑 一起完成一项任务。 这一逻辑可能并不适用 模型以避免依赖关系并使 该模型更易于重用。 这 逻辑也可能不在模型中 因为我们认为模型应该 避免把东西吃掉 要避免的应用程序堆栈 不必要的依赖关系（例如： 模型不会使用服务或服务 控制器）

当可能使用代码时，请使用服务而不是控制器 通过多个模块或控制器

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

对于任何一种功能，考虑将其放置在模型中 第一。如果有令人信服的 不考虑原因，考虑服务 （也考虑开销和 维护新服务的目的）。 如果不需要服务，则 代码将不会在该应用程序中重用 应用程序使用控制器

---

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

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

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

---

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

在您的上下文中，我认为模型和控制器都是业务逻辑的一部分；定义“什么”事物的模型，定义“如何”访问它们的控制器

服务位于顶层，可能将业务逻辑暴露给业务逻辑层之外的任何内容。我同意您的看法，一个服务可能封装多个特定组件（或者更准确地说是模型）

服务和控制器包含逻辑 用于将各种组件连接在一起 完成任务

是的，我也同意你关于避免依赖性等的陈述。该模型不应依赖除其他密切相关模型外的任何东西（）

此外，如果逻辑是特定于一个模型的，那么这就是它应该去的地方；如果逻辑更通用，则应将其置于适当的级别—可能是控制器或公共内部实用程序

使用服务而不是控制器 当代码可由多个用户使用时 模块或控制器

我同意。就grainularity而言，我认为服务处于更高的抽象级别——与“内部”控制器相比，您更可能将服务公开给外部系统

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

它应该只包含适合的逻辑，否则我同意。验证——你可以把它说出来；模型应该明确包含验证使用的规则，但不一定包含验证本身。我见过这两种风格的使用，我不认为有任何错误或正确的答案，只要你是一致的

对于任何一项功能 考虑把它放在模型中 第一。如果有令人信服的理由 不，考虑服务（也） 考虑开销和目的 维护新服务）。如果是服务 是不需要的，代码将不会 在此应用程序中重用使用 控制器

这取决于“功能性”是什么，如果它特定于一个模型，那么它可能属于该模型；如果它对多个模型通用，那么它要么属于控制器，要么属于业务逻辑中的公共实用程序类

当我开始写这一切的时候，我想在你所使用的术语的定义上打下一个基础；我想我还是会把它包括进来——如果我错了，请纠正我：）正如你所看到的，我不清楚在你的上下文中“行动”是什么意思

• 模型：（）“模型用于管理信息，并在信息发生变化时通知观察者；它也是应用程序运行所依据的数据的特定于域的表示形式。”在我看来，这意味着属性等，而不是方法
• 控制器：（）“接收输入并通过调用模型对象启动响应。控制器接受用户的输入，并指示模型和视口根据该输入执行操作。”
• 服务：关于什么是服务有很多不同的观点，我假设在您的上下文中，服务是：一个面向外部的可调用点（在您的系统层的上下文中），它为特定的问题提供特定的答案。（服务通常以bu为基础