3

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

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

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

4

4 回答 4

4

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

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

于 2013-02-22T16:24:51.727 回答
1

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

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

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

于 2013-02-22T16:24:08.270 回答
0

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

于 2013-02-23T01:47:10.627 回答