为什么要为 Spring 控制器使用服务层而不是辅助类？答案

【问题标题】：Why use a service layer instead of a helper class for spring controllers?为什么要为 Spring 控制器使用服务层而不是辅助类？
【发布时间】：2013-02-08 07:55:05
【问题描述】：

根据我的经验，这是我看到使用弹簧控制器的方式：定义一个弹簧控制器，它将某种类型的值返回给表示层。控制器请求映射方法调用服务层。服务层本身由接口和实现组成。服务接口始终只包含一种方法，因此它并不是真正的多态，因为它始终保持“一种形式”。服务实现可以访问某种类型的数据，可能来自 DAO 并将其返回给控制器。控制器可能会在将其返回到表示层之前稍微修改此数据。

在这种情况下，拥有接口的意义何在？我从来没有遇到过从多个控制器调用的spring服务实现，那为什么是接口呢？

使用辅助控制器类执行服务实现的操作不是更有意义吗？

【问题讨论】：

服务的接口不是必须的。有些人使用它们是为了能够编写服务的单元测试实现。
这是由于Abstract Factory 设计模式。也许在您的系统中，您只对服务接口使用一个实现，但您确实可以拥有多个服务实现（取决于需求和应用程序设计）。

标签： java spring model-view-controller

【解决方案1】：

我认为接口是一个好主意，因为它可以让您将业务逻辑保留在实现中，而不必担心如何远程公开它。您可以使接口成为 REST 或 SOAP 服务、EJB 或任何您想要的。输入和输出数据不会改变业务逻辑。它使它与控制器完全分开。您可以在 Web 层之外使用该服务。

【讨论】：

【解决方案2】：

你是对的 - 服务接口往往是特定于用例的，但是仍然有一些很好的理由来创建接口：

这是一个很好的做法。例如，它允许在服务的新实现中进行交换。通过 IDE 提取接口确实没有成本或负面影响。
允许将DynamicProxies 用于事务管理、安全问题等。动态代理比cglib 代理更快，并且它们不需要默认构造函数。 . .此外，在过去，具体对象上的代理有时可能会不稳定，但 DynamicProxies 非常简单，几乎没有出错的余地。
正如 Luke Taylor 所说，它简化了测试。

【讨论】：

【解决方案3】：

使用服务层是有益的，因为它可以很好地将业务逻辑与控制器任务进行逻辑分离。在 Service 类中，您可以封装与 PaymentService 等特定方面相关的业务逻辑。在 PaymentService 中，您可以实现各种方法，例如 cardPayment(), paypalPayment(), refund()。不同的控制器将使用一个单一的服务。而且服务层也便于代码复用。

如果您稍后决定使用一些 AOP 功能，在控制器和服务之间添加一些逻辑（例如日志记录）而不更改其代码，则使用接口很方便。

【讨论】：

【解决方案4】：

使用接口的一个很好的理由是用于测试。如果您想单独测试您的控制器，那么使用接口对模拟或存根最有意义。

【讨论】：