복잡한 MVVM에 대한 도움말 (다중보기)

다음 시나리오에 대한 뷰 모델을 작성하는 데 도움이 필요합니다.

깊고 계층적인 데이터
동일한 데이터 세트에 대한 다중보기
각보기는 활성 선택에 따라 동적으로 변경되는 단일보기입니다.
속성 값에 따라 탭 컨트롤에 다른 유형의 탭 표시

여기에 이미지 설명을 입력하십시오

내 질문 :

각 뷰 (VM1, VM2 등)에 대한 뷰 모델 표현을 만들어야합니까?

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

다음은 단일 뷰의 예입니다

그림 1 : 활성 방을 기준으로 여러 뷰가 업데이트되었습니다. 통지 탭 제어

여기에 이미지 설명을 입력하십시오

그림 2 : 다른 활동 실. 여러 뷰가 업데이트되었습니다. 개체의 속성에 따라 탭 제어 항목이 변경되었습니다.

여기에 이미지 설명을 입력하십시오

그림 3 : 다른 선택 유형. 전체 뷰 변경

여기에 이미지 설명을 입력하십시오

wpf mvvm

— 자야
소스

뮬리 뷰란 무엇입니까? 오식?

— JensG

"Muli view"는 오타였습니다. 동일한 모델 / 뷰 모델에 대해 다른 뷰를 의미했습니다. 내 질문은 각 뷰에 대한 전체 모델 계층 구조를 리모델링 / 랩해야하므로 각 뷰 모델에는 개별 뷰에 필요한 것만 포함되어 있습니까? 아니면 모든 뷰의 속성이 포함 된 단일 뷰 모델 계층을 만들어야합니까? 이 질문을 게시 한 후 두 사람의 장단점을 찾기에 충분히 운이 좋았습니다. 일이 열악하지 않으면 내 경험에 대한 완전한 진단으로 미래 에이 스레드를 업데이트 할 것입니다.

— jayars

디자인 규칙은 일반적인 사항을 먼저 표시 한 다음 세부 사항을 자세히 살펴 보는 것입니다. 그것은 가벼운 전망을 남기고 사용자가 더 깊이 들어가면 새로운 전망이 나타납니다. 따라서 뷰 모델을 분리하여 작은 뷰를 사용하십시오. 이 기사 디자인 사용자 인터페이스 확인

— Csharls

@jsjslim "모든 계층 구조를 동기화 상태로 유지"를 읽었을 때 나는 소리 쳤다. 나는 당신이 멀티 뷰를 갔다는 것을 의심하고, 당신이 그것을 후회했다고 생각합니다. 같은 질문을 할 수있는 다른 독자들을 위해 최소한 빠른 답변을 줄 수 있습니까?

— Guy Schalnat

@ guy-schalnat 멀티 뷰는 요구 사항이었습니다. 내 문제는 뷰 모델을 작성하는 방법을 알아 내려고했습니다. 프로젝트는 여전히 진행 중이며 전체 분석을 작성할 시간을 찾을 수 없습니다. 그러나 요약하면 : 모델 구조를 무시하고 뷰에 중점을 두어야했습니다. 내가 직면 한 복잡성은 자체적으로 부과되었습니다 .WPF의 데이터 바인딩을 너무 심하게 사용하고 싶었습니다. 내가 마지막에 한 것은 좋은 오래된 "복사 / 붙여 넣기 / 리 팩터"였습니다. 등장한 최종 디자인은 가벼우 며 (반복은 거의 없음) 더욱 중요하게 작동했습니다. 앞으로 전체 분석을 작성합니다.

— jayars

답변:

질문에 대답하려면 예, 각 뷰마다 고유 한 뷰 모델이 있어야합니다. 그러나 전체 계층 구조를 모델링 할 필요는 없습니다. 보기에만 필요한 것.

MVVM과 관련된 대부분의 온라인 리소스에서 발생하는 문제 :

대부분의 예에서보기는 모델의 거의 일대일 매핑입니다. 그러나 같은 모델의 다른 측면에 대한 다른 견해가있는 시나리오에서는 두 가지 선택 사이에 붙어 있습니다.

다른 모든 뷰 모델에서 사용되는 단일 뷰 모델

또는 각 뷰마다 하나의 뷰 모델

그러나 둘 다 이상적이지 않습니다.

MVM (Model-oriented View Model)은 코드 중복이 적지 만 유지 관리해야하는 악몽입니다.

VVM (View-Oriented View Model)은 각 뷰에 대해 고도로 특화된 클래스를 생성하지만 중복을 포함합니다.

결국 View 당 하나의 VM을 유지 관리하고 코딩하기가 더 쉽다고 결정했기 때문에 VVM 접근 방식을 사용했습니다.

코드가 작동하면 모든 일반적인 속성과 작업을 현재의 최종 형태로 리팩토링하기 시작했습니다.

이 최종 형태에서 공통 뷰 모델 클래스는 각 VVM으로 구성됩니다.

물론, 나는 여전히 공통적 인 / 전문적인 것으로 간주되는 것을 결정해야합니다. 뷰가 추가 / 병합 / 삭제되면이 잔액이 변경됩니다.

그러나 이것에 대한 좋은 점은 이제 멤버를 공통에서 VVM으로 또는 그 반대로 쉽게 푸시 업 / 다운 할 수 있다는 것입니다.

그리고 객체를 동기화 상태로 유지하는 것에 관한 간단한 참고 사항 :

공통 뷰 모델이 있으면이 대부분을 처리합니다. 각 VVM은 단순히 동일한 공통 뷰 모델에 대한 참조를 가질 수 있습니다.

또한 간단한 콜백 메소드로 시작하는 경향이 있으며 여러 리스너가 필요한 경우 이벤트 / 관찰자로 진화합니다.

정말 복잡한 이벤트 (예 : 예기치 않은 계단식 업데이트)의 경우 중재자 사용으로 전환합니다.

아이가 부모에 대한 역 참조를 가지고있는 코드에서 부끄러워하지 않습니다. 코드를 작동시킬 수있는 모든 것.

리팩토링 할 기회가 생기면 가져 가겠습니다.

내가 배운 교훈 :

못생긴 / 작업 코드> 아름다운 / 비 작업 코드
큰 클래스를 나누는 것보다 여러 개의 작은 클래스를 병합하는 것이 더 쉽습니다.

— 자야
소스

나는 이것을 두 번 공표 할 수 있으면 좋겠다. 이것은 내가 본 옵션에 대한 가장 명확한 설명 중 하나입니다.

— Clever Human

모형을 살펴보면 ViewModels 계층 구조와 많은 작은 뷰를 만드는 것이 좋습니다. 그리고 아마도 원래의 계층 구조를 모델링해야 할 것입니다.

ViewModel간에 동기화를 유지하려면 이벤트를 사용하거나 ViewModel간에 서로 속성을 지정하십시오. 뷰와 뷰 모델 간의 동기화는 표준 알림 속성이어야합니다.

— 크게 기쁘게
소스