在发布-订阅系统中处理事件的不同方式有哪些?



在一个发布-订阅系统中,每个订阅者等待几种类型的事件,还有比简单的切换更好的处理方案吗?

假设我们有两个发行商,Pub1和Pub2;Pub1发送两种类型的事件Pub1- eventa和Pub1- eventb, Pub2也一样,分别发送Pub2- eventa和Pub2- eventb

另一方面,我们有一个订阅Pub1和Pub2事件的客户端Sub1;

如何在Sub1侦听器中处理这些事件?

这里有一些可能性:

一个监听器,一个大开关(难以维护):

Listener{
  HandleEvent(event){
    if(event.type == Pub1-eventA)
       Action1.execute();
    if(event.type == Pub1-eventB)
       Action2.execute();
    if(event.type == Pub2-eventA)
       Action3.execute();
    if(event.type == Pub2-eventB)
       Action4.execute();
  }
}

一个监听器和一个关联映射:

Map<event-type, Action> ActionMap
Listener{
      Action = ActionMap[event-type]
      Action.execute();
}

每个事件类型一个监听器:

ListenerPub1-eventA{ check(event-type); Action1.execute(); }
ListenerPub1-eventB{ check(event-type); Action2.execute(); }
ListenerPub2-eventA{ check(event-type); Action3.execute(); }
ListenerPub2-eventB{ check(event-type); Action4.execute(); }

在"一个监听器,一个大开关"one_answers"一个监听器和一个关联映射"中,每个事件最终仍将在单个孤立的方法中结束,但您将不得不在代码中维护事件的调度。

发布-订阅消息传递系统最重要的贡献是将发布者和订阅者分离。因此,消息路由应该由中间件负责。如果您的中间件不能进行消息路由,那么我建议为每个事件类型设置一个侦听器,以便:

  1. 你不必自己维护消息路由/调度
  2. 每个监听器将有一个单一的责任
  3. 在任何扩展场景中,您可以为任何消息类型添加更多侦听器,而无需触及不相关的侦听器。

这就是我所能想到的。

相关内容

  • 没有找到相关文章

最新更新