모든 메시지를 추적하는 방법

뷰 모델 간의 느슨하게 연결된 통신은 좋은 개념입니다. 프리즘 Eventaggregator와 MVVM Light Toolkit의 Messanger를 사용했습니다.모든 메시지를 추적하는 방법

프로젝트가 커지면 많은 메시지를주고받을 수 있습니다.

내 메시지를 추적하는 가장 좋은 방법은 무엇입니까? 이름 지정 규칙? 패턴? 등 ... 어떻게 추적합니까?

2011-04-28 silverfighter

강력한 형식의 메시지가 포함 된 "Messages"네임 스페이스를 제공하는 데 많은 가치가 있음을 발견했습니다. 잘 정의 된 메시지는 계약/DTO와 유사 할 수 있으므로 최대한 많은 디커플링을 유지하고자하므로 종속성을 최소화해야합니다. 그렇지 않으면 발신자와 수신자 모두 공통 라이브러리에 의존하게됩니다. 때로는 메시지의 특성상 이것이 필요합니다.

많은 메시지가 특정 패턴을 따를 수도 있습니다. 두 가지 공통적 인 메시지 패턴은 Action 및 Command라고 부릅니다. 행동은 "동사"와 "주제"에 가깝습니다.

예를 들어 T Target을 노출하는 MessageAction이있을 수 있으며 작업은 업데이트, 선택, 추가, 삭제 등을 나타내는 열거 형입니다. 일반적이며 일반적인 메시지는이를 감쌀 수 있고 핸들러는 관심있는 유형을 닫는 제네릭

명령은 어딘가에서 시작하여 대상에 작업을 적용하는 작업입니다. 예를 들어 사용자에게 역할을 추가하는 경우 일 수 있습니다. 이 경우 관심있는 항목은 역할이고 대상은 사용자이며 사용자의 조치로 추가됩니다. 그것은 CommandAction이 될 수 있습니다.

메시지를 구성하는 또 다른 일반적인 방법은 공통 인터페이스 또는 기본 클래스를 구현하는 것입니다. 그런 다음 프로젝트의 구현자를 검색하여 메시지가 사용되는 위치를 판별하는 것이 쉽습니다.

출처

2011-04-29 13:07:02

디커플링 메시지 사용시주의를 기울여야하며 드라이버가 필요한 해머로 사용하지 않도록주의하십시오. 예를 들어, 마스터/세부 시나리오에서는 메시지를 사용하여 세부 정보를 알리려고 할 수 있습니다. 그러나 그 메시지에 정말로 관심이있는 것은 무엇입니까? 그렇지 않은 경우 세부 정보에 인터페이스를 표시하고 메신저/이벤트 수집기를 통해 간접적으로 메시지를 직접 보내지 않는 것이 좋습니다. –

좋은 질문입니다. 여기에 제가 사용해온 해결책이 있습니다 만, 대체로 많은 대안이있을 것이고 그에 대한 지침을 찾지 못한 것 같습니다.

기본 이벤트를 확장하는 특정 이벤트를 정의하는 한 가지 방법이 있습니다. 프리즘을 사용하는 일반적인 예는 CompositePresentationEvent의 확장입니다.

그러나 많은 수의 메시지가있는 경우 메시지가 무엇인지 정의하는 것이 유용 할 때가 있습니다. 일반적으로 메시지 헤더, 일부 메시지 속성 및 실제 내용으로 정의 할 수 있습니다. 그런 다음이 메시지를 메시지 버스에 넣을 수 있습니다.

출처

2011-04-28 22:33:03 fabien

모든 메시지를 추적하는 방법

답변

관련 문제