MVVM : 중첩 된 ViewModels 간의 상호 작용을 처리하는 방법은 무엇입니까?

Question

필자는 언급 된 MVVM 패턴을 실험 해왔고 어떤 경우에는 명확한 경계를 정의하는 데 어려움을 겪어 왔습니다. 내 응용 프로그램에서는 컨트롤러에 대한 연결을 만들 수있는 대화 상자가 있습니다. 대화 상자에는 ViewModel 클래스가 있으며, 이는 매우 간단합니다. 그러나 대화 상자에는 추가 컨트롤러 (ContentTemplateSelector으로 선택)가 있습니다.이 컨트롤은 연결된 컨트롤러 유형에 따라 다릅니다. 이 컨트롤에는 자체 ViewModel이 있습니다.

내가 겪고있는 문제는 확인을 눌러 대화 상자를 닫을 때 실제로 요청 된 연결을 만들어야하는데, 이는 내부 Controller 관련 ViewModel 클래스에 캡처 된 정보가 필요합니다. 단순히 컨트롤러 고유의 ViewModel 클래스 모두가 연결을 구성하는 공통 인터페이스를 구현하도록 유혹하고 있지만 내부 ViewModel이 실제로이 구성을 담당해야합니까?

내 일반적인 질문은 ViewModel이 서로 어떻게 상호 작용해야하는지에 대한 일반적으로 받아 들여지는 디자인 패턴이 무엇인지, 특히 '부모'VM이 무엇을해야 하는지를 알기 위해 '자식'VM의 도움이 필요할 때 그렇습니까?

---

편집 : 나는 원래 생각했던 것보다 조금 청소기의 디자인을 마련 않았다,하지만 난 여전히이 작업을 수행 할 수있는 '권리'방법입니다 있는지 확실하지 않습니다

. ContentTemplateSelector가 컨트롤러 인스턴스를보고 연결 작성자에게 표시 할 컨트롤을 마술처럼 찾도록 허용하는 백엔드 서비스가 있습니다. 나에 대해 저를 괴롭히는 것은 최상위 수준의 ViewModel이 생성 된 컨트롤에 대해 DataContext을보고 적절한 인터페이스로 캐스팅해야한다는 것입니다. 나쁜 생각처럼 보입니다 (View의 DataContext은 ? 연결)

나는 이런 식으로 뭔가 함께 상처는() 단순화 :

public interface IController 
{ 
    IControllerConnectionBuilder CreateConnectionBuilder(); 
} 

public interface IControllerConnectionBuilder 
{ 
    ControllerConnection BuildConnection(); 
} 

나는 나의 내부 뷰 모델 클래스는 IControllerConnectionBuilder를 구현해야하고, 컨트롤러 내부 뷰 모델을 반환합니다. 그런 다음 최상위 ViewModel이 IControllerConnectionBuilder을 (가상 마법 메커니즘을 통해) 시각화합니다. 여전히 내 안의 ViewModel이 건물을 수행한다는 것을 조금은 귀찮게하지만, 적어도 현재 내 최상위 ViewModel은 더러운 세부 사항을 알 필요가 없습니다. (시각화 된 컨트롤이 ViewModel).

더 자세히 정리할 방법이 있으면 추가 생각을 환영합니다. ViewModel에 대해 '괜찮은'책임이 얼마나 많은지 아직 확실하지 않습니다.

Answer 1

뷰 모델 간 상호 작용에 적합한 옵션은 뷰 모델 클래스 사이에있는 observer 클래스에 직접 바인딩하는 것입니다.

Answer 2

최상위 레벨 ViewModel을 NestedViewModel의 존재를 인식하고 싶다고 생각합니다. 계층 적 관점에서 볼 때 마스터보기에는 하위보기가 포함됩니다.

당신의 본능은 옳습니다. 중첩 된 ViewModel이 최상위 레벨에서 사용자 작업에 의해 시작된 동작을 노출하는 것이 정확하다고 생각하지 않습니다. 대신, 최상위 레벨 ViewModel은 연관된 뷰에 대한 동작을 제공해야합니다.

하지만 연결 구성에 대한 책임을 ICommand으로 옮기고 최상위 레벨 ViewModel을 통해이 명령을 표시하는 방법을 고려해 보겠습니다. 마스터 대화 상자의 OK 버튼을 클릭하면이 명령에 바인드되며이 명령은 최상위 레벨 ViewModel에 위임합니다. 예를 들어 실행시 ViewModel.CreateConnection()을 호출합니다.

따라서 중첩 된 컨트롤의 책임은 데이터를 포함하여 소비하기 위해 데이터를 NestedViewModel으로 수집하고 노출하는 것이고, 이론적으로 동일한 정보를 입력해야하는 다른 상황에서 재사용 가능합니다 (if any) - 이미 생성 된 연결을 편집하기 위해 다시 사용하고 싶다고 가정 해 봅시다.

다른 유형의 NestedViewModel이 근본적으로 다른 데이터 세트를 노출하는 경우에만 주름이 생길 수 있습니다.

예를 들어, 하나는 호스트 이름 및 속성으로 포트를 노출, 다른 하나는 사용자 이름 및 비밀번호를 노출합니다.

최상위 수준의 ViewModel.CreateConnection()이 여전히 깨끗한 방식으로 작동하려면 인프라 작업을해야 할 수도 있습니다. 소량의 중첩 된 컨트롤 유형이있는 경우에는 노력할 가치가 없을 수도 있지만 간단한 NestedViewModel 형식 검사와 캐스트로 충분할 수 있습니다.

소리가 나나요?

Answer 3

최근 Unity (Microsoft Enterprise 라이브러리)를 사용하여 종속성 삽입을 실험했습니다. 이는 두 뷰 모델이 서로간에 필요로하지 않는 것을 완전히 정의하는 인터페이스를 사용할 때 갈 길입니다. MEF는 제가 알고있는 의존성 주입을위한 또 다른 옵션이 될 것입니다.

HTH