为什么我们需要服务层？答案

【问题标题】：Why do we need service layer?为什么我们需要服务层？
【发布时间】：2018-03-08 15:23:57
【问题描述】：

我目前正在学习 Spring Boot，我已经看到人们如何创建控制器、注入服务类以及在服务类中注入存储库。

为什么我们需要服务类作为中间人，为什么我们不能将存储库注入控制器？

【问题讨论】：

这个问题可能会吸引固执己见的答案（您可以看到当前的答案已经发生了这种情况），所以我投票决定以主要基于意见来结束这个问题。相关：What topics can I ask about here?.

【解决方案1】：

您并不总是需要服务层。尤其是如果您的 API 只是简单的 CRUD 操作，例如，不需要真正的逻辑或计算。

但是，如果您有一个 API 在查询您的存储库之前执行一些逻辑，那么它应该在一个单独的服务类中。这是源于所谓的单一责任原则的良好做法。

【讨论】：

【解决方案2】：

这种争论通常支持分层架构：

我们使用层来允许我们抽象出底层实现，以便我们可以轻松更改它。

分层的一个令人愉快的副作用是 - 如果忠实地遵循 - 它可以通过 (a) 使用接口来定义每一层和 (b) 鼓励关注点分离，从而使系统更具可测试性。

所以，这就是原则（至少简单地说），但就像任何原则一样，它可能会被误解和误用。

虽然分层以隐藏视图层的数据访问（反之亦然）的好处在大多数情况下是可靠的，但在视图层和数据层之间包含一个服务层的好处是并不总是那么引人注目。一个系统...

...可能不需要服务层。

然而，一个具有...的系统

...可能确实需要一个服务层。

【讨论】：

【解决方案3】：

这是一种将服务功能与传输分开的方法，您的服务定义了一个涵盖单一职责 (SOLID) 的功能，并且可以使用不同的端口（六角架构）公开，例如 HTTP/REST 或 AMQP。

添加服务层让您可以灵活地在未来更改端口，或使用多个端口。

【讨论】：

【解决方案4】：

就是这样，你不必在 RestController 层中放很多代码，它应该是干净的，并且只包含与通信相关的代码。

所以所有的逻辑和 IF 等都应该留在 Controller 层。

Repository层应该坚持interface的方式，方法里面不应该有任何代码，只有数据获取方式的布局，而不是它的逻辑。

【讨论】：

【解决方案5】：

Spring 引导控制器是一个与外部世界的接口，例如与 UI 没有太大区别。就像您希望能够拥有一种以上的 UI 风格一样，您的业务逻辑可能会有多个界面。特别是如果您希望它长期存在并适应未来的 API 框架。如果您的逻辑嵌入在控制器中，那么当您到达该点时，您必须进行相当多的重构。

所以需要一个单独的控制器取决于你的逻辑的复杂性。

【讨论】：