2009-10-23 5 views
4

내 WPF MVVM 응용 프로그램에서 내 모델은 런타임에 지속적으로 변경되는 Model 객체의 복잡한 트리입니다. 모델 인스턴스는 런타임에 실행되고 이동하며 트리 내에서 위치를 변경하고 물론 많은 속성을 변경합니다. 내보기는 거의 해당 트리의 일대일 시각적 표현입니다. 모든 모델 인스턴스는 트리의 노드 인 사례의 80 %에 있습니다.ViewModel 트리 대 자주 업데이트되는 모델 트리

제 질문은 이제 어떻게이 모델에서 ViewModel을 디자인 할 수 있을까요? 내 문제는 꽤 많은 속성을 가진 상당히 다른 모델 유형이 많이 있다는 것입니다. MVVM을 이해했다면 뷰는 모델과 직접 통신해서는 안되므로 각 모델 유형에 대한 ViewModel 유형을 작성해야하며 ViewModel에서 모델 유형의 각 특성을 다시 랩해야합니다.

또한 ViewModel은 모델의 propertychanges에 "바인딩"하여 뷰에 전달해야합니다 (wpf datatbinding 사용). 내가 새로 나타나는 각 모델에 대해 ViewModel 인스턴스를 생성하고 소개하는 일부 팩토리가 필요하며 해당 모델이 사라지면 각 ViewModel 인스턴스를 처분해야합니다. 내가 만든 모든 사례를 추적합니다. 얼마나 많은 부 풀리는 코드가이 이중 포장에 얼마나 많은 돈을 지불하는지 믿을 수 없습니다. 정말 좋은 접근 방법입니까? 각 엔티티와 각 속성은 두 번 더 적게 존재하며 모델과 뷰를 동기화 된 상태로 유지하는 추가 코드가 많이 있습니다. 어떻게 처리합니까? 이 문제를 해결할 더 영리한 방법이 있습니까?

아무에게도 이보다 나은 참조/샘플 구현이 있습니까?

답변

9

이 경로를 따르면 패러다임의 함정에 빠질 수도 있습니다. MVVM은 단순히 WPF 세계에서의 개발을 단순화하는 패턴 일뿐입니다. 그렇지 않은 경우 사용하지 않거나 접근 방식을 수정하십시오. "MVVM 사용"필드를 확인하기 위해 80 %의 시간을 보내지는 않습니다.

지금 다시 질문하기. 내가 틀렸다면 정정하되 MVVM을 반대 방향에서보고있는 것처럼 들린다. 모델 ~ ViewModel 일대일 대응. 일반적으로 View를 기반으로 ViewModel을 만들고, 그 다음에는 모델을 기반으로 ViewModel을 만듭니다.

일반적으로 그래픽 디자이너의 화면 모형을보고 해당하는 ViewModel을 작성합니다. 모델에서 필요한 모든 필드를 감싸고/수정/형식화/결합하여 View 개발을 가능한 한 쉽게 만듭니다.

당신은 View가 모델과 거의 일대일로 시각적으로 표현되었다고 말했습니까? 이 경우 모델 트리의 루트 객체를 노출하는 매우 간단한 ViewModel을 생성하고 해당 속성을 통해 View에서 직접 모델을 사용하게 할 수 있습니다. 그런 다음 View 사용자 정의 또는 명령 처리가 필요한 경우 ViewModel에 위임 할 수 있습니다.

매우 모호한 답변입니다. 어쩌면 당신이 더 구체적인 질문을한다면 우리는 혼란을 덜어 줄 수 있습니다.) ...

+0

+1 패러다임을 너무 문자 그대로 받아들이지 않기 위해 매우 철저한 대답과 좋은 제안. –

+0

+1 "보통 View를 기반으로 ViewModel을 만들고 처음에는 Model *을 만듭니다" – Amsakanna