풍부한 모델이있을 때 무엇을합니까?

Question

나는 (POCO 대신) 모든 곳에서 풍부한 모델을 가지고있는 프로젝트에서 기존 코드로 작업하고 있습니다. 기본적으로 코드를 반복하지 않고도 풍부한 모델과 ViewModel을 섞는 좋은 방법이 있습니까?

---

• 부자 모델은 데이터 유효성 검사가 있습니다. 이러한 것들을 ViewModels과 함께 재사용하기위한 쉬운 방법은 없습니까?

예 :

당신이 리치 모델이있는 경우 redundent 코드를 MVVM을 유지하면서 그 활용하고 피할 수있는 방법이 기본적으로 ... 하나의 예입니다

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo 
{ 
    private Person _person; 

    [Required] //This seems redundent... 
    public String FirstName { ... } 
} 

public class Person 
{ 
    [Required] 
    public String FirstName { ... } 
} 

? 내 모델이 어떤 데이터 컨텍스트이거나 ViewModel에 완전히 노출되는 것을 피하고 싶습니다. 예를 들어

: MVVM의

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo 
{ 
    private Person _person; 

    //This seems like a bad thing to do... 
    public Person ThePerson { get { return _person; } } 
} 

Answer 1

하나의 아이디어는 데이터 영역에서 프리젠 테이션 층을 분리하는 것이다. 이렇게하면 데이터 영역의 데이터를 변경하지 않고도 프레젠테이션 계층이 작업중인 데이터를 변경할 수 있습니다.

따라서 프리젠 테이션 레이어의 데이터는 사용자 요청에 따라 데이터 레이어에만 기록됩니다. 중복 FirstName 속성은 간단한 "모든 변경 실행 취소"와 같은 항목을 구현할 수있는 유연성을 제공하는 레이어 테두리로 사용됩니다.

데이터 바인딩에 필요한 값 변경에 대한 알림을 처리하는 일반적인 ValueViewModel을 사용하는 것이 좋습니다. 모델이 다시 데이터 계층에서 프레젠테이션 계층을 분리 무엇에서 INotifyPropertyChanged 인터페이스를 구현하지 않아도이 패턴을 사용하여

public class PersonViewModel : INotifyPropertyChanged, IDataErrorInfo 
{ 
    private Person _person; 

    [Required] //This seems redundent... 
    public ValueViewModel<String> FirstName { ... } 
} 

: 뷰 모델과 같이 보일 것이다이 방법에 따라.

MVVM은 매우 가벼운 패턴이며 첫 번째보기에서 다소 형식적으로 보일 수도 있지만 패턴을 따르면 큰 유연성을 제공합니다. MVVM 규칙을 위반하는 경우 mvvm을 사용하여 얻은 유연성을 파괴하기 때문에 전체 애플리케이션 아키텍처 파일을 위험에 처하게됩니다. 따라서 MVVM을 위반할 계획이라면 MVVM을 전혀 사용하지 않는 것에 대해 생각해보십시오.

Answer 2

View 용 ViewModel에서 전체 Model을 노출해도 아무런 문제가 발생하지 않습니다. 나는 그것이 "MVVM-Purist"접근법이 아니라는 것을 알고 있지만 간단하고 빠르며 잘 작동합니다.

그러나 두 방법 모두 똑같이 유효하며 대개 모델과 ViewModel을 분리하면 장기적으로 쉽게 사용할 수있는 매우 큰 코드 기반의 경우도 있습니다. 이 경우 ViewModel 유효성 검사에서 ModelValidation을 반환하지 않는 것이 어떻습니까? DataAnnotations를 사용하는 것만 큼 예쁜 것은 아니지만 여러 곳에서 유효성 검사를 만들지는 않을 것입니다.

public string GetValidationError(string propertyName) 
{ 
    string s = null; 

    switch (propertyName) 
    { 
     case "FirstName": 
     case "LastName": 
      s = Person.GetValidationError(propertyName); 
      break; 
    } 

    return s; 
} 

string IDataErrorInfo.this[string propertyName] 
{ 
    get { return this.GetValidationError(propertyName); } 
} 

Answer 3

이것은 고전적인 질문의 무언가이다 :

예를 들어, 나는 종종이 같은 것을 사용합니다.

모델 클래스를 표현 계층 별 인터페이스 및 속성으로 "오염"시키면 하나의 논리적 모델 버전 만 있으면 효율적이지만 프리젠 테이션 및 비즈니스 모델은 독립적으로 발전 할 수 없습니다.

모델을 "순수하게"유지하고 별도의 뷰 모델을 유지하면 각 모델에서 유연성을 얻지 만 두 버전을 유지 관리 (및 매핑)해야하므로 효율성이 떨어집니다.

이론적 관점에서 볼 때 더 복잡한 시스템의 경우에는 후자를 추천합니다. 시스템이 상대적으로 단순하고 (CRUD라고 생각할 때) 두 가지 유형의 모델을 독립적으로 발전시킬 필요가 없다고 생각하면 아마도 이전 모델로는 꽤 안전 할 것입니다. 분명히 두 가지 방법은 상호 배타적이지 않으며 화면 단위로 화면에 대한 결정을 내리는 것은 전례가되지 않습니다.