ViewModel을 Model과 정확히 동일하게 추가하는 것이 좋습니다

내 솔루션에 다음 레이어가 있습니다.

1. App.Domain
2. App.Service
3. App.Core (이 App.DataLayer라고도 함)
4. App.Web

소프트웨어 디자인 패턴은 제 질문이 아닙니다. Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

뷰 (예 : 홈페이지) 에서이 모델을 사용 Id, Name & Value하고 싶고을 사용하고 싶습니다 . 따라서 ViewModel을 만들려면 다음을 추가하십시오.

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

좋은 생각입니까? 또는 Foo대신에 FooViewModel?

이것은 처음에는 DRY 규칙을 위반하는 것처럼 보일 수 있지만, "유사하고 동일한 코드"가 다른 작업을 수행하거나 독립적으로 변경할 수있는 경우 반드시 "반복적"인 것은 아니라고 주장합니다. 그리고 뷰 모델의 경우, 코드는 "클라이언트"가 보는 것을 정의합니다. 반드시 비즈니스가 말하는 엔티티와 오퍼레이션은 아닙니다. 따라서 종종 "우연히 동일한"모델을 클라이언트 나 인터페이스에 공개합니다. 비즈니스 규칙 및 용어 또는 최종 사용자 용어를 서로 독립적으로 변경할 수 있습니다.

질문을 다시하겠습니다. 도메인이 변경되면 "버전 1"클라이언트가 이전 인터페이스를 계속 사용할 수 있습니까? "핵심 비즈니스 규칙"의 일부가 아닌 인터페이스에서 용어 또는 오퍼레이션을 공개 하시겠습니까? 그 반대?

이러한 종류의 질문을 염두에두고, 뷰의 "기능"이 기본 도메인 모델을 엄격하게 공개하는 것이라면 그렇습니다. 이것은 DRY 규칙을 위반하는 것처럼 보입니다.

_{또한 일부 언어에서는 멤버 속성과 리플렉션을 사용하여 모델 변경을 통해보다 자연스럽게 변경되는 뷰를 표시 할 수 있습니다. (또는 다른 영리함을 통한 반복 횟수 가 줄어든다 . 그러나 "영리함"은 종종 반복을 정당화하지 못한다.}

Foo 인스턴스라는 하나의 속성 만 포함하는 뷰 모델이 있습니다. 이렇게하면 정의에 따라 DRY를 위반하지 않고 Foo가 변경되면 뷰 모델이 자동으로 변경 사항을보고 뷰 모델과 모델의 직접적인 관계가 없어지게됩니다.

내일 뷰에 Foo뿐만 아니라 다른 것을 표시 해야하는 경우 새 속성을 추가하면 뷰 모델의 의도가 여전히 명확하고 Foo와 다른 것이 포함되어 있습니다. Foo의 속성과 관련이없는 다른 속성의 혼합.

뷰 모델을 FooViewModel로 생각하지는 않지만 뷰를 표시 해야하는 관점에서 생각합니다. Foo가 하나만 표시되면 뷰 모델에 Foo라는 하나의 속성이 포함됩니다.

내가 분명히 설명했는지 확실하지 않습니다. 그렇지 않은 경우 알려 주시면 깨어있을 때 다시 말씀 드리고 다시 말씀 드리겠습니다!

FooViewModel이런 식으로 사용 하면 DRY 교장을 위반한다고 말할 수 있습니다. 변경해야 Foo할 경우에도 변경해야 FooViewModel합니다. 나는 당신이 단순히 Foo당신의 관점을위한 모델로 사용하는 것이 더 나을 것이라고 생각합니다 . Foo의 항목과 다른 항목을 표시 해야하는 경우 뷰 모델을 고려하십시오. 예를 들어, 일부 정보를 렌더링하는 데 필요하다고 Foo도에서를 Bar.