Spring Boot应用中service层有什么用？

Question

我是 Spring Boot 的新手，我正在创建一个没有 UI 的 RESTful API。

我在想是否应该使用业务服务并从那里调用存储库，还是直接从我的 REST 控制器调用存储库？

Answer 1

服务层不是 Spring Boot 独有的概念。它是一个软件架构术语，经常被称为模式。简单的应用程序可以跳过服务层。实际上，没有什么能阻止您从控制器层调用存储库方法。

但是，我强烈建议使用服务层，因为它主要用于定义应用程序边界。服务层职责包括（但不限于）：

• 封装业务逻辑实现；
• 集中数据访问；
• 定义事务开始/结束的位置。

引用Martin Fowler 的企业应用程序架构模式目录中的服务层模式：

服务层从接口客户端层的角度定义了应用程序的边界及其可用操作集。它封装了应用程序的业务逻辑，在其操作的实现中控制事务和协调响应。

Answer 2

关注点分离是关键：

• 控制器（表示层或端口）是一个协议接口，它将应用程序功能公开为 RESTful Web 服务。它应该仅此而已。
• 存储库（持久层或适配器）抽象了持久性操作：查找（通过 id 或其他标准）、保存（创建、更新）和删除记录。它应该仅此而已。
• 服务层（域）包含您的业务逻辑。它定义了您提供的功能、访问方式以及传递和返回的内容 -独立于任何端口（其中可能有多个：Web 服务、消息队列、计划事件）并独立于其内部工作（它是服务使用存储库，甚至数据在存储库中的表示方式与任何人无关）。服务层可以从存储库数据 1:1 转换，或者可以应用过滤、转换或附加数据的聚合。

业务逻辑一开始可能很简单，不会提供更多那么简单的 CRUD 操作，但这并不意味着它将永远保持这种状态。一旦您需要处理访问权限，就不再是将请求从控制器直接路由到存储库的问题，而是检查访问和过滤数据的问题。请求在访问数据库之前可能需要验证和一致性检查，可能会应用规则和其他操作，因此您的服务会随着时间的推移获得更多价值。

即使对于简单的 CRUD 情况，我也会引入一个服务层，它至少可以将 DTO 转换为实体，反之亦然。

让您的控制器/存储库（或端口和适配器）保持愚蠢，让您的服务保持智能，您将获得一个可维护且可测试的解决方案。