Каковы различные способы обработки событий в системе публикации-подписки?

Question

В системе публикации-подписки, где каждый подписчик ожидает нескольких типов событий, есть ли лучшее решение для обработки, чем простой коммутатор?

скажем, у нас есть 2 издателя, Pub1 и Pub2; Pub1 отправляет два типа событий Pub1-eventA и Pub1-eventB, то же самое для Pub2 с соответственно Pub2-eventA и Pub2-eventB

С другой стороны, у нас есть клиент Sub1, который подписывается на события Pub1 и Pub2;

Как бы вы справились с обработкой этих событий в слушателе 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(); }

Answer 1

В «Один слушатель, один большой коммутатор» и в «Один слушатель и карта ассоциации» каждое событие все равно будет заканчиваться в одном изолированном методе, но вам придется поддерживать диспетчеризацию событий в вашем коде.

Важнейшим вкладом систем обмена сообщениями «публикация-подписка» является разделение издателей и подписчиков.Так что маршрутизация сообщений должна быть ответственностью вашего промежуточного программного обеспечения.Если ваше промежуточное программное обеспечение не способно к маршрутизации сообщений, то я бы предложил использовать одного прослушивателя для каждого типа события, чтобы:

1. Вам не приходилось самостоятельно поддерживать маршрутизацию / диспетчеризацию сообщений
2. Каждый слушатель будет нести единоличную ответственность
3. В случае любого сценария масштабирования вы можете добавить больше слушателей для любого типа сообщения, не касаясь несвязанных слушателей.

Это все, что я могу придумать.

Надеюсь, это поможет.