2011-08-15 5 views
0

이후 이벤트 수집기를 사용하여 이벤트를 사용하는 대신 이벤트 수집기를 사용하여 메시지를 게시하는 방법을 배웠습니다. 코드에서 WPF 제어 속성을 코드에 연결하는 이벤트를 제외한 대부분의 이벤트를 관리했습니다. 이제 문제는 제가 실제로 처리기로 서비스를 오버로드하고있는 것 같습니다. GitHub 주위를 순회하면서 사람들이 이벤트 수집기 (버스와 같은 다른 이름을 사용하는 것처럼 보임)를 구현하고 각 유형의 메시지를 처리하는 클래스를 생성하는 것을 볼 수 있습니다. 예를 들어메시지 게시 기반 프로그래밍?

: 용어가 프로그램의이 유형에 사용되는 무슨

public class SomeHandler : IHandle<SomeMessage> 
{ 
    private readonly IEventAggregator _eventAggregator; 

    public SomeHandler(IEventAggregator eventAggregator) 
    { 
     _eventAggregator = eventAggregator; 
     _eventAggregator.Subscribe(this); 
    } 

    public void Handle(SomeMessage message) 
    { 
     Console.WriteLine("Handled SomeMessage."); 
    } 
} 

? 그것에 대해 더 자세히 알고 싶습니다.

+1

당신은 아마도합니까 평균 CQRS을 찾기 위해 구글 수 ? 꽤 많은 사람들이 요즘 CQRS에 대해 이야기하고 있으며, CQRS는 일반적으로 "bus"또는 "dispatcher"명령과 별도의 명령 처리기 클래스와 같은 것을 포함합니다. 일부 링크 : [cqrsinfo.com] (http://cqrsinfo.com/), [Rinat Abdullin의 CQRS 시작점] (http://abdullin.com/cqrs/), [Udi Dahan의 명확한 CQRS] (http : //www.udidahan.com/2009/12/09/clarified-cqrs/). – stakx

답변

4

이것은 특히 고전 Mediator Pattern에 기초한다 : 매개체 패턴

는 개체 간의 통신은 조정자 객체로 캡슐화된다. 객체는 더 이상 서로 직접 통신하지 않지만 대신 중재자를 통해 통신합니다. 이렇게하면 통신하는 오브젝트 간의 종속성이 줄어들어 결합이 낮아집니다.

특정 코드 예제는 Caliburn Micro'sEventAggregator 인 것으로 보입니다. 현재 Mediator Pattern의 많은 구현은 "Event Aggregators"라고하며 MVVM Pattern 라이브러리의 공통 구성 요소입니다. 그것은 메시징 패턴입니다.

메시징 패턴의 측면에서, 다음 책들의 관심을 끌 수있을 것입니다 :

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

는 응용 프로그램 내 구성 요소를 분리하는 메시징을 사용하는 것보다, 시스템 통합 메시징을 사용하는 방법에 대한 자세한하지만.

+0

+1 책 – jgauffin

3

나는 이것을 pub/subscribe이라고 부릅니다.

좀 더 현대적인 접근법은 제어 컨테이너의 반전을 사용하여 메시지의 모든 가입자를 얻는 것입니다.

var subscribers = _container.ResolveAll<ISubscriberOf<IMyMessage>>(); 
foreach (var subscriber in subscribers) 
{ 
    subscriber.Handle(myMessage); 
} 

는 또한 "event driven architecture"더 흥미로운 구현