为什么人们在他们的代码中使用消息/事件总线？[已关闭]

event-handling events design-patterns java

2022-08-31 16:20:23

我想你已经听说过消息/事件总线，它是系统内所有事件流动的单一位置。在计算机的主板和LAN网络中也可以找到类似的体系结构。对于主板和网络来说，这是一个很好的方法，因为它减少了电线的数量，但它对软件开发有好处吗？我们没有像电子产品那样的限制。

消息总线/事件总线最简单的实现可以是这样的：

class EventBus {
    void addListener(EventBusListener l}{...}
    void fireEvent(Event e) {...}
}

发布事件是使用 bus.fireEvent（event）完成的，接收消息由 bus.addListener（listener）启用。这种架构有时用于软件开发，例如MVP4G为GWT实现类似的消息总线。

活跃项目：

休眠/死亡项目：

Sun/Oracle JavaBeans InfoBus
https://eventbus.dev.java.net/ [断开的链接]

这只是流行的Observer（监听器）模式“全局”制作 - 系统中的每个对象都可以监听每条消息，我认为这很糟糕，它打破了封装原则（每个对象都知道一切）和单一责任原则（例如，当某些对象需要一种新类型的消息时，事件总线经常需要更改，例如在Listierer类中添加新的Lister类或新方法）。

由于这些原因，我认为对于大多数软件来说，观察者模式比事件总线更好。您如何看待事件总线，它对典型应用有什么好处吗？

编辑：我不是在谈论像ESB这样的“大”企业解决方案 - 它们可能很有用（更重要的是ESB提供了很多，不仅仅是一个事件总线）。我问的是使用消息总线在“常规”Java代码中进行对象到对象连接的有用性 - 有些人这样做，请检查上面的链接。事件总线可能是电话到电话通信或计算机到计算机通信的最佳解决方案，因为网络中的每个电话（或计算机）通常可以相互通信，并且总线减少了电线的数量。但是对象很少相互通信 - 一个对象可以有多少个协作者 - 3，5？

答案 1

我正在考虑使用内存中的事件总线作为我的常规java代码，我的理由如下

系统中的每个对象都可以监听每条消息，我认为这很糟糕，它打破了封装原则（每个对象都知道一切）

我不确定这是否属实，I类需要从事件总线注册开始，类似于观察者模式，一旦类在事件总线上注册，只有具有适当签名和注释的方法才会被通知。

和单一责任原则（例如，当某些对象需要新类型的消息时，事件总线通常需要更改，例如在监听器类中添加新的监听器类或新方法）。

我完全不同意

事件总线经常需要更改

事件总线永远不会更改

我同意

add a new Listener class or a new method in the Listener class

这如何打破SRP？，我可以有一个BookEventListener，它订阅与我的Book Entity有关的所有事件，是的，我可以向这个类添加方法，但这个类仍然是有凝聚力的......

为什么我打算使用它？它帮助我模拟我的域的“时间”....

通常我们会听到一些事情，例如“当”购买书籍时发送邮件

我们去写下来

book.purchase();
sendEmail()

然后我们被告知在购买书籍时添加审核日志，我们转到上面的代码段

book.purchase();
sendEmail();
**auditBook();**

就在那里违反了OCP

我更喜欢

book.purchase();
EventBus.raiseEvent(bookPurchasedEvent);

然后根据需要继续添加处理程序打开扩展关闭以进行修改

谢谢

答案 2

有些人喜欢它，因为它是立面模式或中介模式的体现。它集中了跨领域活动，如日志记录、警报、监视、安全等。

有些人不喜欢它，因为它通常是单例失败点。每个人都必须了解它。