【问题标题】:Design pattern for Multiple services beans in SPring bootSpring Boot 中多服务 bean 的设计模式
【发布时间】:2021-04-26 02:36:18
【问题描述】:

我正在开发一个 Spring Boot 服务项目,其中我们有多个 Spring Service bean,它们相互自动连接。

例如:

@Service
public class Service1

@Autowire
Service2, Service3
.
.
.
@Service
public class Service5
@Autowire
Service 4, Service 1

@Repository
public interface Service1Repository extends JpaRepository<Entity1, UUID>
.
.
.
@Repository
public interface Service5Repository extends JpaRepository<Entity5, UUID>

大多数服务 bean 都自动装配到另一个服务 bean 中,同时将它们对应的存储库 bean 与其他一些 bean(ModelMapper、一些应用程序上下文 bean)自动装配在一起 有时这会导致循环依赖问题,有时会导致代码质量检查失败,因为通过构造函数注入自动装配的 bean 超过 9 个。

我的问题是,有没有最佳实践或设计模式来构建这些应用程序 spring bean?

【问题讨论】:

    标签: java spring spring-boot design-patterns microservices


    【解决方案1】:

    我不能确切地说,因为我不知道这些服务到底在做什么。但看起来您有许多“事务脚本”作为服务公开,即您在每个服务中都有一个自上而下的程序类型的计算。并且在某些时候,开发人员看到了服务中的重复,并决定在它们之间自动连接。

    服务层基本上可以充当事务脚本,或者将域对象连接在一起并将它们公开给控制器或其他层。话虽如此,可以在其他服务中注入服务,但是它们太多了,正如您所说,循环依赖似乎是一个问题。

    我的最佳猜测是,该项目最初是一个事务脚本,但现在它发展成为需要域模型的东西。也许您应该尝试识别与业务逻辑相对应并且可以在不同服务之间重用的对象。这应该会减少服务的数量。

    这更像是一个架构问题而不是设计问题。

    如果不进一步了解服务的性质,就不能说太多。

    【讨论】:

      【解决方案2】:

      我的建议如下:

      • 如果可测试性不是您主要关心的问题(即强制执行类级别的不变量),请不要通过构造函数注入自动装配,请尝试使用字段注入。这有助于代码质量检查。
      • 尝试主要围绕模型对服务进行分组。例如,对于模型 Person 有一个 PersonRepository 和一个仅操作 Person 类型对象的 PersonService。此外,仅从其相应的服务方法调用存储库方法。
      • 对于复杂的业务案例,有专门针对您要解决的业务问题的服务类。例如,如果您正在实施员工排班应用程序,则有一个用于生成名册的服务,另一个用于通知员工他们当前的日程安排,另一个用于将名册导出到 Google 表格。

      您的问题没有详细说明这些服务的目的是什么。如果您评估 Strategy、Factory、Builder 或 Composite 设计模式是否对您的案例有帮助,这将是有益的。

      【讨论】:

      猜你喜欢
      • 2021-02-11
      • 2017-04-10
      • 2019-11-29
      • 1970-01-01
      • 1970-01-01
      • 2014-12-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多