服务层是否位于控制器和模型（映射器）之间？

Question

3

我发现自己需要将一些功能移入服务层。在这个特定的例子中，它涉及到与zend-paginator相关的示例。

在这个示例中，服务层只是控制器和模型之间的一个中间阶段。看起来这是它的预期角色，在某些情况下似乎很有道理。

但这引发了一些问题。

首先，我是否可以轻松地将示例服务代码移动到控制器中而不会受到任何惩罚？这样做是否能通过减少一层代码来使我受益？

假设将代码移动到服务层有实际好处，那么我的映射器交互的其余部分会发生什么？控制器访问服务层执行某些任务，而映射器执行其他任务吗？还是服务层成为所有映射器交互的代理？

对于诸如从表单创建新行之类的事情，似乎服务层并没有增加任何价值，因此它将只是在服务层水平上进行传递函数。

使用它来完成某些任务似乎会在以后使事情变得更加复杂，而将其用作代理似乎是故意引入代码复制和复杂性。

任何关于“最佳实践”的澄清都将非常有帮助。

- Stryks

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user934258 · Accepted Answer

将代码移动到控制器会导致一个臃肿的控制器。它会将应用程序与UI紧密耦合在一起。这使得在不同的上下文中执行该操作变得困难。一个瘦控制器通过使用一个或多个服务来生成响应，在特定的上下文中处理请求。

这些服务以一种松散耦合的方式与模型交互，定义了应用程序（领域逻辑）的边界，可以集成到不同的上下文中。

例如，在MVC应用程序中，控制器与服务层进行交互。控制台包装器可以在cli上与服务层进行交互。SOAP或JSON-RPC服务器可以使用反射将服务公开为Web服务API。所有这些都可以在不重复代码的情况下完成。