在 Spring Boot 应用程序中组织服务、服务实现和存储库的最佳实践

Question

大多数应用
程序中都可以找到示例项目结构在大多数 Spring Boot 应用程序中，都有 JPA 存储库、服务和服务实现。谁能解释一下优缺点

1. 仅在需要时才使用存储库
   
2. 使用服务类及其应用程序。
   
3. 使用服务接口并使用实现。

不同的博文有不同的解释。寻求专家经验。

Answer 1

首先，每个设计模式都是为了解决软件开发中的一个常见问题。如果您确定在特定用例中不会遇到这些问题，则无需遵循这些模式。

1. 您可以直接从控制器或任何需要的地方调用存储库。存储库应该执行基本的数据库操作，如果您只需要这些，调用它们就没有问题。

2. 但大多数时候，您希望在使用数据库之前/之后执行一些业务逻辑。这就是涉及服务类的地方（SOLID原则之一是单一职责原则——您不应该在同一个类中同时拥有持久性操作和业务逻辑）。例如，您调用 EmployeeService.save() 方法来保存员工，该方法执行业务逻辑（例如，检查员工的 ID 号是否正确），然后调用存储库类（仅将员工保存在数据库）。

3. 接口和实现模式是最后一个的扩展。如果需要新功能，拥有一个接口可以使您的应用程序在未来更容易维护。理想情况下，您的大部分应用程序将调用该接口，并提供适当的实现（例如，通过注入 Spring 组件）。例如，如果一年后您需要一个执行不同业务逻辑的特殊实现，您可以只实现该接口并根据需要注入 bean。

这就是为什么大多数开发人员通过使用存储库-接口-实现结构来保证他们的应用程序面向未来的原因。如果您确定只需要基本的 CRUD 操作，则无需创建服务。

Answer 2

1. 仅在需要时才使用存储库-->您应该仅在需要时创建并使用它；没关系。一般来说，除非你确实需要，否则最好不要创建某些东西。

2. 使用 Service 类并使用它--> Service 只是您通过从存储库类（DAO-数据访问对象层）获取一些数据来编写业务逻辑的类；将它们分开是很好的做法；这样 DAO 或服务的任何更改都不会相互影响。

3. 用户服务接口和实现并使用该实现。

一般来说，您根据接口进行编码；其良好的设计和编码实践；这样你就可以创建松散耦合的代码；因此，无论您在哪里使用服务，您都可以将其作为接口类型注入，并且其带下划线的实现可以插入和拔出；当然，如果您的服务接口有多个实现。例如，您的 ShapeService 接口有两种不同的实现，供两个不同的客户端计算面积，其中一个客户端有兴趣计算 Recatangle 的面积，而另一个客户端感兴趣的是 Square 的面积。因此，在这种情况下，如果您创建 Service 接口及其 Impl；您可以保持要使用此 Service 接口的类的逻辑完整或不变。另外，未来如果有很多形状的实现，也很容易改变；您的代码设计将对扩展开放，但对修改关闭。

我建议如果您有服务类的单一实现，那么直接使用类，而不是创建 Service 接口，然后单独的 Impl 类；