EventAggregator vs CompositeCommand

Question

나는 프리즘 안내를 통해 내 길을 가졌으며 대부분의 커뮤니케이션 차량을 이해했다고 생각합니다.

명령은 매우 간단하므로, 대표단이 뷰를 모델과 연결하는 데 사용될 것임이 분명합니다.

교차 모듈 통신과 관련하여, 특히 복합 명령을 통해 EventAggregation을 사용하는 시점은 다소 명확하지 않습니다.

실질적인 효과는 예를 들어 동일합니다

• 이벤트 게시 -> 모든 가입자는 통지를 받고 응답으로 코드를 실행합니다.
• Composite 명령을 실행합니다 -> 모든 등록 된 명령이 실행되고 첨부 된 코드가 실행됩니다.

두 사람은 "Fire and Forget"라인을 따라 작동합니다. 즉, 이벤트를 해고/명령을 실행 한 후 가입자의 응답에 신경 쓰지 않습니다.

두 후드 아래의 구현이 매우 다르다는 것을 이해하지만 사용량의 실질적인 차이를 보는 데 어려움이 있습니다.

그래서 우리는 그것이 실제로 무엇을 의미하는지 생각해야합니까 - 이벤트? 그것이 일어날 때 (이벤트가 발생)? 사용자가 "웹 요청 완료"처럼 직접 요청하지 않은 것?

그리고 명령? 이는 사용자가 무언가를 클릭하여 신청서에 직접 서비스를 요청하여 명령을 발행 했습니까?

그게 다야? 또는 이러한 통신 차량 중 하나를 다른 통신 차량 중 하나를 사용하는시기를 결정하는 다른 방법이 있습니까? 이 지침은 내가 읽은 최고의 문서 중 하나이지만 구체적인 설명은 제공하지 않습니다.

따라서 프리즘에 참여/사용하는 사람들이 이것에 대해 약간의 빛을 발하는 데 도움이되기를 바랍니다.

Answer 1

이 둘 사이에는 두 가지 주요 차이점이 있습니다.

1. 명령에 대한 실행성. 명령은 명령을 호출하여 실행에 유효한 지 여부를 말할 수 있으며, raisecanexecutechanged ()와 해당 CANExecute 대리인이 거짓으로 반환되도록합니다. "모든 저장"CompositeCommand의 경우 몇 가지 "저장"명령을 합성하는 경우를 고려하면 하나 실행할 수 없다고 말하는 명령 중에서 모든 버튼 저장 버튼이 자동으로 비활성화됩니다 (니스!).
2. EventAggregator는 메시징 패턴이며 명령은 명령 패턴입니다.. CompositeCommands는 명시 적으로 UI 패턴이 아니지만 암시 적으로 (일반적으로 버튼 클릭과 같은 입력 동작에 연결됨). EventAggregator는 이러한 방식이 아닙니다. 응용 프로그램의 모든 부분은 EventAggregator 이벤트를 효과적으로 제기합니다 : 백그라운드 프로세스, 뷰 모델 등. 필터링, 백그라운드 스레드 실행 등과 같은 것들을 지원하는 응용 프로그램 전반에 걸쳐 메시징을위한 중개 도구입니다.

이것이 차이점을 설명하는 데 도움이되기를 바랍니다. 각각을 언제 사용 해야하는지 말하기가 더 어렵지만 일반적으로 나는 험의 규칙을 사용합니다. 이벤트를 제기하는 사용자 상호 작용이라면 다른 것에 대한 명령을 사용하고 Eventaggregator를 사용하십시오..

도움이 되었기를 바랍니다.

Answer 2

또한 한 가지 더 중요한 차이점이 있습니다. 현재 구현으로 EventAggregator의 이벤트는 다음과 같습니다. 비동기, CompositeCommand는 동기.

"이벤트 X가 발생한 것을 알리십시오. 이벤트 X가 실행될 이벤트 핸들러에 의존하는 일을하십시오"와 같은 것을 구현하려면 Application.Doevents ()와 같은 작업을 수행하거나 CompositeCommands와 같은 작업을 수행해야합니다.