MVC (Asp.Net MVC 특히)에서 모델을 단일 뷰로 나타내야합니까? 나에게

Question

, 이것은 약간의 의미를 보이지만, 다음의 정보를 읽은 후 :

http://weblogs.asp.net/scottgu/archive/2010/02/05/asp-net-mvc-2-release-candidate-2-now-available.aspx

http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html

(특히 주석의 일부) http://blog.stevensanderson.com/2010/02/19/partial-validation-in-aspnet-mvc-2/#comment-35397

그것은 나타납니다 Asp.Net MVC의 배경은 모델과 뷰 사이에 일대일 관계가 있다는 것입니다. 이것은 DRY 원칙과 몇 가지 다른 표준 프로그래밍 방식에 위배되는 것 같습니다.

예를 들어 사용자 계정 모델이 있고 사용자가 편집 할 수있는보기가 두 가지 있는데 하나는 사용자가 직접 편집 할 수 있고 다른 하나는 사이트 관리자가 편집 할 수있는보기입니다. 관리자는 내부의 필수 항목에 대한 추가 필드에 액세스 할 수 있지만 사용자는이를 볼 수 없거나 편집 할 수 없습니다. 위에 언급 된 게시물에 설명 된 모델 바인딩 기능과 신념에 따라 각 페이지마다 하나씩 두 개의 개별 사용자 모델을 만들어야하며 유일한 차이점은 추가 필드입니다. 이것은 단순한 예일뿐입니다. 정확하게 동일한 객체에 대해 5 개 또는 6 개의 다른 모델을 의미하는 곳을 보았습니다. 각보기 사이의 필드가 다를 수 있습니다. 그건 정말 나에게 이해가되지 않습니다.

Answer 1

내가 언급 한 게시물을 읽지는 않았지만 몇 가지보기에 대해 하나의 모델을 갖는 데는 아무런 문제가 없습니다.

사용하지 않는 필드가 있어도이 UserModel을 가지고 모든보기에서 사용합니다.

상황이 조금 더 복잡해 지지만 사용자가 여전히 많이 공통적 인 경우 usermodel (User.Address)에 대해 집계를 사용하거나 Interfaces (사용자 필드가 street이고 city가 IAddress를 구현 함)를 사용할 수 있습니다.

두 가지 방법 모두 대부분의 경우에 사용되는 집계와 함께 장단점이 있습니다.

나는 그들이 검증을 다루는 것을보고 게시물을 읽은 후 편집

. 이것은 다른 이야기입니다. DataAnotations를 사용하려면 유효성 검사가 다를 경우 다른 클래스가 있어야합니다. 나는 DataAnnotations를 사용하지 않는다 - 그래서 나는 당신의 클래스 디자인이 다를지도 모른다고 생각한다.

Answer 2

ASP.NET MVC에서 모델 당 하나의보기 만있는 공식적인 요구 사항은 없습니다. 많은 경우 코드 복제가 발생합니다.

필자는 개인적으로 모델보기 종속성, 즉 모델 당 하나의보기를 분리하려고합니다. 장래에 얼마나 비슷한 모델 - 뷰 쌍이 발전 할 것인가라는 것을 모를 때가 있습니다. 별도의 모델이라면 변경 사항을 하나만 소개하면이 모델에 종속 된 다른 뷰를 "수정"할 필요가 없으며 한꺼번에 모든 모델에 대한 추가 작업을 수행 할 필요가 없습니다.

Answer 3

특수 효과를 사용하는 경우 하나의 '모델'과 여러 개의 '보기 모델'을 고려해야합니다. 기본 모델을 몇 가지 다른 시각에서 보여 주어야하기 때문에 현재의 앱에서 뷰 모델을 사용하여 혜택을 얻었습니다.

Answer 4

TL : DR : 많은 뷰 모델을 만듭니다. 그들은 저렴하고 유연합니다.

"DRY 원칙과 몇 가지 다른 표준 프로그래밍 방식에 위배되는 것 같습니다."

[표창장 필요]?

MVC는 모든 언어 또는 패턴에서 각 개별 화면에 대한보기 모델 정의를 작성해야한다는 사실을 변경하지 않습니다. 속성을 통해, XML을 통해, 웹 양식 컨트롤을 토글하는 등을 통해.

DRY 주체는 대개 반복되는 비즈니스 논리와 관련이 있습니다. CRUD 화면 섹션에서 FirstName 속성을 반복하는 것은 큰 문제가 아닙니다. 심지어 5-6 번, 그게 뭐죠? 40 초?

객체 지향 클래스에 대한보기 모델을 실수로 작성한 경우 homoiconisticish screen 표현을 채우지 않을 경우 모든 상속 및 비즈니스 논리가 적용됩니다.

바보 뷰 정의를 만들 때 실제로 프로그래밍하지 않아야합니다. 이 작업은 Access GUI에서 쉽게 수행하거나 XML로 정의 할 수 있습니다. 화면보기 모델이 C#에 있다는 사실만으로도 데이터를 채우고 배송하고 WCF 및 Automapper와 같은 도구로 작업하는 것이 더 쉽습니다.