【问题标题】:Does the service layer sit between the controller and the model (mapper)?服务层是否位于控制器和模型(映射器)之间?
【发布时间】:2012-04-27 21:37:51
【问题描述】:

我发现自己需要将一些功能移至服务层。在这种特殊情况下,它与有关 zend-paginator 的 example 相关。

在示例中,服务层只是控制器和模型之间的中间阶段。看来这是它的预期角色,在certain circumstances 下似乎很有意义。

不过,这对我提出了一些问题。

首先,我是否可以不那么容易地将示例服务代码移至控制器而不会受到任何真正的惩罚,这对我来说不会因为删除一层代码而受益吗?

假设将代码移动到服务层有切实的好处,那么我的映射器交互的其余部分会发生什么?控制器是否会为某些任务访问服务层而为其他任务访问映射器,或者服务层是否会成为所有映射器交互的代理?

对于诸如从表单创建新行之类的事情,服务层没有添加任何值,因此它实际上相当于服务层级别的传递函数。

将它用于某些任务似乎会使以后的事情变得复杂,而将其用作代理似乎是我们故意引入代码复制和复杂性。

任何关于“最佳实践”的说明都会非常有帮助。

【问题讨论】:

    标签: zend-framework service-layer


    【解决方案1】:

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

    这些服务通过以松散耦合的方式与模型交互来定义应用程序的边界(域逻辑),这种方式可以集成到不同的上下文中。

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

    【讨论】:

    • 感谢您的回复。从您的帖子开始,大概是服务层中包含的逻辑量​​和应用程序的交互要求决定了对服务层的需求。此外,假设一旦服务层到位,所有模型交互都会通过它。我理解正确吗?
    猜你喜欢
    • 2014-07-07
    • 1970-01-01
    • 1970-01-01
    • 2023-04-01
    • 1970-01-01
    • 2011-10-07
    • 1970-01-01
    • 1970-01-01
    • 2012-02-02
    相关资源
    最近更新 更多