iir*_*ekm 60 java events design-patterns event-handling
我认为您已经听说过消息/事件总线,它是系统中所有事件流动的单一位置.在计算机的主板和LAN网络中可以找到类似的架构.这对于主板和网络来说是一个很好的方法,因为它减少了电线的数量,但它对软件开发有好处吗？我们没有像电子产品那样的限制.
消息总线/事件总线的最简单实现可以是:
class EventBus {
void addListener(EventBusListener l}{...}
void fireEvent(Event e) {...}
}
发布事件是通过bus.fireEvent(事件)完成的,接收消息由bus.addListener(侦听器)启用.这种体系结构有时用于软件开发,例如MVP4G为GWT实现类似的消息总线.
活跃项目:
休眠/死亡项目:
它只是流行的Observer(Listener)模式"全局" - 系统中的每个对象都可以监听每条消息,我认为这很糟糕,它打破了封装原则(每个对象都知道所有内容)和单一责任原则(例如,某些对象需要一种新类型的消息,事件总线通常需要更改,例如在Listener类中添加一个新的Listener类或一个新方法.
由于这些原因,我认为,对于大多数软件来说,Observer模式比事件总线更好.您如何看待事件总线,它对典型应用程序有什么好处？
编辑:我不是在谈论像ESB这样的"大型"企业解决方案 - 它们可能很有用(ESB提供的内容远远超过事件总线).我在询问有关在"常规"Java代码中使用消息总线进行对象到对象连接的有用性 - 有些人这样做,请查看上面的链接.事件总线可能是电话到电话通信或计算机到计算机通信的最佳解决方案,因为网络中的每个电话(或计算机)通常可以相互通信,并且总线减少了电线的数量.但是对象很少相互交谈 - 一个对象可以拥有多少合作者 - 3,5？
Sud*_*han 66
我正在考虑使用内存事件总线为我的常规Java代码,我的理由如下
系统中的每个对象都可以监听每条消息,我认为这很糟糕,它打破了封装原则(每个对象都知道所有内容)
我不确定这是否真的如此,我的类需要注册事件总线开始,类似于观察者模式,一旦类已经注册到事件总线,只有具有相应签名和注释的方法被通知.
和单一责任原则(例如,当某个对象需要新类型的消息时,通常需要更改事件总线,例如在Listener类中添加新的Listener类或新方法).
我完全不同意
事件总线经常需要更改
事件总线永远不会改变
我同意
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);
然后根据需要继续添加处理程序打开扩展已关闭以进行修改
谢谢
duf*_*ymo 26
有些人喜欢它,因为它是Facade模式或Mediator模式的体现.它集中了交叉活动,如日志记录,警报,监控,安全等.
有些人不喜欢它,因为它通常是单身人士的失败点.每个人都必须了解它.
Bal*_*Bal 16
我在JavaScript中大量使用它.可能有许多不同的小部件都需要在其他事情发生时进行某种操作 - 对象的所有权没有真正的层次结构.不是将每个对象的引用传递给每个对象,或者只是使每个对象都是全局的,当特定小部件内发生重大事件时,我可以发布"/ thisWidget/somethingHappened" - 而不是用特定的各种代码填充该小部件到其他小部件的API.我有一个包含所有"接线"或"plubming"的类,因为他们喜欢在Java Spring框架中调用它.这个类包含对我所有小部件的引用,并且包含了每个各种事件触发后发生的所有代码.
它集中,易于访问和维护,如果有一件事发生变化或者我想在特定事件上发生新进程,我不必搜索每一个类/对象/小部件来试图找出某些东西正在处理中.我可以去我的"操作员"类 - 在特定事件发生时处理所有"接线"的类,并看到该事件的每一个反响.在此系统中,每个窗口小部件都完全与其他窗口小部件无关.它只是简单地发布它发生的事情或它正在做的事情.
Qwe*_*rky 14
我无法理解你在问题中真正提出的问题.你举一个简单的事件总线的例子,实际上只是Observable用不同的名字,然后你说;
由于这些原因,我认为,对于大多数软件来说,Observer模式比事件总线更好.您如何看待事件总线,它对典型应用程序有什么好处？
..但是举个例子,它们是一样的.这让我想知道你是否曾经使用过像Enterprise Service Bus这样的东西.在基础级别,ESB在逻辑上与观察者模式做同样的事情,但商业产品增加了很多,甚至更多.它就像一个类固醇的事件总线.它们是复杂的软件产品和提供;
消息拾取
通过侦听各种端点生成事件.端点可以是侦听器(例如HTTP服务器),消息传递系统(例如JMS),数据库或其他任何您想要的东西.
消息路由
获取事件并将其发送到一个/多个端点.路由可以非常智能,总线可以根据消息类型,消息内容或任何其他标准来路由消息.路由可以是智能和动态的.
消息转换
将您的消息转换为另一种格式,这可以像从XML到JSON或从数据库表上的行到HTTP请求一样简单.转换可以在数据本身内发生,例如交换日期格式.
数据丰富
通过在此过程中调用服务来添加或修改消息中的数据.例如,如果消息中包含邮政编码,则总线可以使用邮政编码查找服务来添加地址数据.
..还有很多很多.当你开始寻找到的细节,你可以真正开始看到为什么人们使用这些东西.