.net事件总线开发案例_我的事件总线案例

.net事件总线开发案例

注意：由于我本周参加了Joker会议 ，因此我必须在“以微服务方式发展”系列中稍作休息。 但是，希望您亲爱的读者仍然喜欢这篇文章。

与咖啡机旁的同事进行非正式的交谈是提高开发人员技能的好方法。 大多数时候，人们不同意，这是学习上下文思考的好方法。 最新主题之一是关于事件总线。 尽管没有Android开发人员，但我是移动团队的一员，该团队使用事件总线在应用程序的不同组件之间调度事件。 令人惊讶的是（至少对我而言），一个团队成员“不喜欢Event Bus”。 碰巧的是，几天后我才刚读完这篇文章 。

我想为事件总线辩护是我的提示。

有多种实现消息传递的抽象，想到的第一个可能是观察者模式。 您可以在各种UI框架（例如AWT，Swing，Vaadin）中实现它。 尽管它将调用者的责任从订阅者（ 也称为观察者）转换为观察者（ 也称为主题），但这种模式有一个很大的缺点：为了使订阅者收到有关观察者事件触发的通知，观察者必须持有对集合的引用的订阅者。 尽管不是通常意义上的，但这直接转化为它们之间的强耦合 。

为了减少耦合，通常的解决方案是在两者之间插入第三方组件。 您知道我要去哪里：该组件是事件总线。 现在，观察者无需注册到主题，而是注册到事件总线，并且主题将事件发布到事件总线。

现在，主题和观察者之间的耦合已替换为主题和事件总线之间的耦合：Observable不需要实现以订户类型作为参数的register()方法。 因此，事件可以来自任何来源，并且该来源可以及时更改，而订阅者则无需进行任何重构。

在Java世界中，我知道3种不同的实现事件总线的库：

• 绿色机器人 （针对Android）
• Square的Otto （也针对Android）（感谢@dpolyshuk进行了 更新 ）
• 番石榴
• Vaadin Spring Boot的事件总线

在最近的两个中， notify()方法的实现被注释的使用代替，而在前者中，它基于一个已达成共识的方法签名（ 即 onEvent(Event<T>) ）。 因此，可以通知任何类型，而无需实现Observer接口，从而进一步减少了耦合。

最后，所有这些实现都提供了一种以事件的形式传递额外有效负载的方法。 这是最终的设计：

这种设计的优点是多方面的：

• 无需在代码片段中同时引用Subscriber和Observable即可使后者注册前者
• 无需实现Observer接口
• 能够传递额外的有效载荷
• 多对多关系：一个订阅者可以订阅不同的事件，一个可观察者可以发送不同类型的事件

唯一的问题是事件的发布顺序，但这可能是一个问题，具体取决于您的上下文。 在这种情况下，传统的耦合方法调用方法更适合。 在所有其他情况下-特别是在用户界面层中，甚至在使用真正的图形组件（AWT，Swing，Android，Vaadin等）进行设计时，您都应该充分利用Event Bus的所有优点。

例如，这是一篇有关将Guava Event Bus与Vaadin集成在一起的旧文章 ，但仍然很相关。

翻译自: https://blog.frankel.ch/my-case-for-event-bus/

.net事件总线开发案例