게시 - 가입 시스템에서 이벤트를 처리하는 다른 방법은 무엇입니까?

Question

각 구독자가 여러 가지 유형의 이벤트를 기다리는 게시 - 구독 시스템에서 간단한 스위치보다 나은 처리 솔루션이 있습니까?

두 게시자 인 Pub1 및 Pub2가 있다고 가정 해 보겠습니다. Pub1은 두 가지 유형의 이벤트 Pub1-eventA 및 Pub1-eventB를 전송합니다. Pub2-eventA 및 Pub2-eventB와 Pub2도 동일합니다.

한편 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(); } 

Answer 1

"하나의 리스너, 하나의 거대한 스위치"와 "하나의 리스너와 연관지도"에서 각 이벤트는 여전히 하나의 분리 된 방법으로 끝나지 만 코드 내에서 이벤트 디스패치를 ​​유지해야합니다.

게시 - 구독 메시징 시스템의 가장 중요한 기여는 게시자와 구독자를 분리하는 것입니다. 따라서 메시지 라우팅은 미들웨어의 책임이어야합니다. 각 리스너가

해야합니다 직접 파견/메시지 라우팅을 유지하기 위해

1. 시작할 필요가 없습니다 : 미들웨어는 메시지 라우팅 할 수없는 경우, 그때 있도록 이벤트 유형 당 하나의 리스너가는 제안 단일 책임
2. 규모가 큰 시나리오의 경우 관련없는 리스너를 건드리지 않고도 모든 메시지 유형에 대해 더 많은 수신기를 추가 할 수 있습니다.

내가 생각할 수있는 전부입니다.

이 정보가 도움이되기를 바랍니다.