组织 Spring Boot 事件/事件侦听器的最佳实践答案

【问题标题】：Best practice to organize SpringBoot Events/EventListeners组织 Spring Boot 事件/事件侦听器的最佳实践
【发布时间】：2020-11-26 08:06:42
【问题描述】：

我认为这与观察者和发布/订阅模式密切相关，但由于我还没有看到使用它的生产代码，我对你们在 SpringBoot 中使用事件和事件监听器时如何组织代码有一些疑问（尽管我相信它可以扩展到任何语言/框架）。

假设我有 3 个班级及其各自的服务：

Foo with FooService
Bar with BarService
Baz with BazService

当 FooService 创建一个 Foo 对象时，我希望 BarService 和 BazService 执行一些代码来更新它们各自的表，例如，我发布了FooCreatedEvent。

由于我有 2 种不同的服务，这里的最佳做法是什么？

解决方案 1：

一个封装一切的类

public class FooEventListener {

    @Autowired
    private BarService barService;
    @Autowired
    private BazService bazService;

    @EventListener
    public void handleFooCreatedEvent(FooCreatedEvent event) {
       barService.doSomething(event);
       bazService.doSomething(event);
    }

}

解决方案 2：

2 个类，每个类都封装了自己的服务

public class BarEventListener {

    @Autowired
    private BarService barService;

    @EventListener
    public void handleFooCreatedEvent(FooCreatedEvent event) {
       barService.doSomething(event);
    }

}

public class BazEventListener {

    @Autowired
    private BazService bazService;

    @EventListener
    public void handleFooCreatedEvent(FooCreatedEvent event) {
       bazService.doSomething(event);
    }

}

在设计方面我喜欢解决方案 2，但我认为让 BarEventListener 处理 FooEvents 可能有点令人困惑

你们觉得呢？

【问题讨论】：

标签： java spring-boot events design-patterns event-handling

【解决方案1】：

第一个解决方案的缺点是每次新服务想要监听时都必须编辑类，因此很可能违反开放/封闭原则。第二种解决方案的缺点是它创建了一个并行继承层次结构，使所需的类数量增加了一倍，并且仍然必须进行编辑才能让新服务侦听。

但服务本身可以实现自己的@EventListener 方法。这样，新服务就不需要编辑其他类和类层次结构。如果BarService 想监听FooCreatedEvent，那么它可以在自己内部实现自己的监听器方法，而不是在单独的类中。

【讨论】：