모델 -view-ViewModel 패턴의 DRY 위반?

Question

도메인 엔터티가 있고 기본적으로 실제 엔터티 개체의 하위 집합 인보기 가능한 엔터티가있는 실버 라이트 응용 프로그램 내에서 MVVM 패턴을 사용하는 방법에 대해 오늘이 기사를 읽었습니다. http://dotnetslackers.com/articles/silverlight/Silverlight-3-and-the-Data-Form-Control-part-I.aspx 이것은 DRY 원칙을 명백히 위반하지 않습니까? 그렇다면 어떻게하면 좋은 방식으로 처리 할 수 ​​있습니까?

Answer 1

나는 개인적으로 디노가 거기에서하는 일을 좋아하지 않으며 나는 같은 방식으로 문제에 접근하지 않을 것이다. 일반적으로 VM은 모델 클래스의 필터링 된 그룹화 된 정렬 컬렉션으로 생각합니다. VM은 뷰에 대한 직접 매핑이므로보기에서 사용되는 여러 CollectionViews (고객에 대해 하나의 CV, 제품에 대해 다른 CV, 아마도 둘 다 필터링 됨)가있는 NewOrderViewModel 클래스를 만들 수 있습니다. 모델의 모든 클래스에 대해 완전히 새로운 VM 클래스를 만드는 것은 제 생각에는 DRY를 위반합니다. 필요에 따라 모델을 보강하기 위해 파생 클래스 또는 부분 클래스를 사용하여 특정 (종종 계산 된) 속성보기에 추가합니다. IMO .NET RIA Services는 M 및 VM 데이터를 클라이언트와 서버 모두에서 사용할 수있는 추가 보너스와 결합하여 구현하는 데 적합합니다. 디노는 똑똑한 사람이지만,이 사람을 데리고 나가는 길은.

Answer 2

DRY는 원칙이지만 엄격한 규칙은 아닙니다. 당신은 인간이며 차별화 될 수 있습니다. 예. DRY가 실제로 어려운 규칙 인 경우 두 변수에 동일한 값을 할당하지 마십시오. 평범하지 않은 프로그램에서는 값이 0 인 변수를 두 개 이상 가질 것입니다.

일반적으로 DRY는 일반적으로 데이터에 적용되지 않습니다. 이러한 뷰 특정 엔티티는 주목할만한 로직이없는 데이터 전송 오브젝트 일 것입니다. 모든 종류의 이유로 데이터가 중복 될 수 있습니다.

Answer 3

답변은 실제로 ViewModel에 있어야한다고 생각하는 것에 달려 있다고 생각합니다. 나를 위해 ViewModel 현재 표시되는 화면의 모델을 나타냅니다.

ViewCategoryViewModel과 같은 항목의 경우 범주의 필드가 중복되지 않습니다. Category 객체를 ViewModel의 속성 (예 : "SelectedCategory"아래),보기에 표시해야하는 다른 데이터 및 화면에서 사용할 수있는 명령으로 표시합니다.

도메인 모델과 뷰 모델 간에는 항상 유사점이 있지만 ViewModel을 만드는 방법은 모두 유사합니다.

Answer 4

데이터 전송 개체 (DTO)와 동일합니다.

두 개체 유형에 대한 도메인 그래서 은 DRY의 위반이 아니다, 다르다.

class Customer 
{ 
    public int Age 
} 

그리고 corsponding보기 모델 : - 전혀 다른 속성 유형 - 다른 개체

class CustomerViewModel 
{ 
    public string Age; 

    // WPF validation code is going to be a bit more complicated: 
    public bool IsValid() 
    { 
     return string.IsNullOrEmpty(Age) == false; 
    } 
} 

에 differnt 도메인

는 다음과 같은 예를 생각해 보자.