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

时间:2018-12-27 08:05:41

标签: java spring-boot jpa

Sample project structure that can be found in most of the appliations
在大多数Spring Boot应用程序中,都有JPA存储库,服务和服务实现。谁能解释

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

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

2 个答案:

答案 0 :(得分:2)

1。仅在需要时使用存储库->您应该仅在需要时创建和使用它;没关系。通常,除非您确实需要,否则最好不要创建任何东西。

2。使用Service类并使用-> Service只是通过从存储库类(DAO数据访问对象层)中获取一些数据来编写业务逻辑的类。保持隔离的优良作法;这样DAO或服务中的任何更改都不会相互影响。

3。用户服务界面,然后实施并使用实现。

通常,您根据接口进行编码;良好的设计和编码实践;这样,您可以创建松散的耦合代码;因此,无论您在哪里使用服务,都可以将其作为接口类型及其带下划线的实现注入,可以插入和拔出;当然,如果您的Service接口有多种实现。 例如,您的ShapeService接口有两种不同的实现方式,供两个不同的客户端计算Area,其中一个客户端有兴趣计算Recatangle的面积,而另一个客户端在Square中。因此,在这种情况下,如果您创建Service接口及其Impl;您可以将要使用此Service接口的类的逻辑保持不变或不变。同样在将来,如果有很多形状实现方案,则很容易更改。您的代码设计可以进行扩展,但可以进行修改。

我建议您对服务类使用单一实现,然后直接使用类而不是创建Service接口,然后再分离Impl类;

答案 1 :(得分:1)

首先,制定每种设计模式以解决软件开发中的常见问题。如果您确定在特定用例中不会遇到这些问题,则无需遵循这些模式。

  1. 您可以直接从控制器或任何需要的位置调用存储库。存储库应该执行基本的数据库操作,并且只要您需要就可以调用它们。

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

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

这就是为什么大多数开发人员都使用存储库接口实现结构来对应用程序进行过时验证的原因。如果您确定只需要基本的CRUD操作,则无需创建服务。