我发现自己需要将一些功能转移到服务层。在这种特殊情况下，它涉及关于zend-paginator的example。
在该示例中，服务层只是控制器和模型之间的临时阶段。这似乎是它的预期角色，在certain circumstances下似乎很有道理。
但它为我提出了一些问题。
首先，我是否可以轻松地将示例服务代码轻松移动到控制器而不会有任何实际损失，这会不会因为删除一层代码而使我受益？
假设将代码移动到服务层有一个明显的好处，那么我的映射器交互的其余部分会发生什么呢？控制器是为某些任务访问服务层而为其他任务访问映射器，还是服务层成为所有映射器交互的代理？
对于诸如从表单创建新行这样的事情，服务层不会添加任何值，因此它实际上相当于服务层级别的传递函数。
将它用于某些任务似乎会使以后复杂化，而将其用作代理似乎是我们故意引入代码复制和复杂性。
对最佳做法的任何澄清＆＃39;会非常有帮助的。
答案 0 :(得分：1)
将代码移动到控制器会导致胖控制器。它将应用程序与UI紧密结合。这使得在不同的上下文中执行该操作变得困难。瘦瘦的控制器通过使用一个或多个服务来生成响应来处理特定上下文中的请求。
这些服务通过以松散耦合的方式与模型交互来定义应用程序的边界（域逻辑），可以集成到不同的上下文中。
例如，控制器与MVC应用程序中的服务层交互。控制台包装器可以与cli上的服务层进行交互。 SOAP或JSON-RPC服务器可以使用反射将服务公开为Web服务API。所有这一切都可以在不重复代码的情况下完成。