我的代码在哪里？控制器，服务还是型号？

Question

因此，我们有一个PHP + Zend框架+ 1.2学说的应用程序，具有以下结构：

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

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

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

下面是我们的开发团队已经拿出指引，但我在任何反馈/输入非常感兴趣，对他们：

1. 服务和控制器包含 逻辑搭售各种组件 共同完成一个任务。 此逻辑可能不在 模型中以避免依赖关系，并使 模型更具可重用性。 这 逻辑也可能不是在模型 因为我们认为该模型应该 避免食用的东西了 应用程序栈，以避免不必要的 依赖（例如：在 模式将不消耗服务或 控制器）。
2. 当代码可能由多个模块或控制器使用 时，使用服务而不是控制器。
3. 模型应该包含尽可能多的逻辑，但避免 引用应用程序特定的 功能。通常，型号 至少包含验证逻辑。
4. 对于任何一项功能，首先考虑将其放置在型号 中。如果有一个引人注意的原因，请考虑服务 （同时考虑开销和 用于维护新服务）。 如果不需要服务，并且 代码将不会在此 应用程序中重复使用，请使用控制器。

Answer 1

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

服务位于顶层，可能会将业务逻辑暴露给业务逻辑层以外的任何东西。我同意你的看法，一个服务可能封装多个特定组件（或者更精确的模型）。

服务和控制器包含逻辑 用于捆扎各种组件一起 以完成任务。

是的，我也同意你的说法就避免依赖关系等模型不应该依赖于任何excpet等密切相关模型（Common Closure Principle）。另外，如果逻辑是特定于模型的 - 那么这就是它应该去的地方;如果逻辑更通用，它应该放在适当的级别 - 可能是一个控制器或一个通用的内部工具。

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

我同意。就粒度而言，我会看到服务处于更高的抽象层次 - 与“内部”控制器相比，您更可能向外部系统公开服务。

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

它应该只包含适合在那里的逻辑，否则我同意。验证 - 你可以提取出来;该模型应该明确包含验证使用的规则，但不一定包含验证本身。我已经看到两种风格都使用了，只要你保持一致，我认为没有错误或正确的答案。

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

它取决于“functinality”是什么，如果它是特定于模型，那么它可能属于模型;如果它对于多个模型是共同的，那么它或者属于控制器或者业务逻辑中的普通工具类。

当我开始撰写所有这些内容时，我想围绕您所使用的术语的定义进行实地考察;我想我会加入它 - 如果我错了，请纠正我的错误:)正如你所看到的，我并不清楚你在上下文中的“动作”是什么意思。

• 型号：（from Wikipedia - MVC）“该模型被用来管理信息，并且当该信息改变通知观察员;它也是在其上的应用程序进行操作的数据的特定于域的表示”在我看来，这意味着属性等 - 而不是方法。
• 控制器：（from Wikipedia - MVC）“接收输入并通过在模型对象上调用来启动响应。控制器接受来自用户的输入并指示模型和视口根据该输入执行操作。
• 服务：对于什么服务有很多不同的看法，我假设在你的上下文中服务是：一个面向外部的可调用点（在系统层次的上下文中）为特定问题提供特定的答案。 （服务通常基于业务概念而不是技术服务。）
• 行动：我不明白你明确表示的意思。

Answer 2

我相信你应该把你的业务逻辑放在服务层。这背后的原因是业务逻辑应该是数据结构/模型的一个单独问题。

与大多数情况一样，您经常会发现数据结构和业务逻辑紧密交织，因此可能没有足够的分隔来证明我的第一条语句。不过，我认为这通常指向代码味道。

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

我同意模型应该包含尽可能多的内在聚焦逻辑，但模型需要是非特定的。业务逻辑是一个消耗应用程序模型的用例，因此应该是分开的。