asp.net MVC는 View-Model을 도메인 모델로 캡슐화해야합니까?

도메인 객체가 뷰에 직접 전달되는 MVC 예제가 많이 있습니다. 뷰가 단순하면 잘 작동합니다.asp.net MVC는 View-Model을 도메인 모델로 캡슐화해야합니까?

일반적인 대안은 도메인 모델과보기에 필요할 수있는 추가 속성 (예 : 'confirmPassword')과 동일한 속성을 모두 가진보기 모델을 만드는 것입니다.

너무 많이 읽고 AutoMapper를 발견하기 전에 필자는 도메인 객체 (또는 다중 도메인 객체)가 뷰 모델의 속성 일 뿐인 뷰 모델의 변형을 만들기 시작했습니다.

나는 나쁜 일을 했습니까? 이 방법으로 얻을 수있는 문제점이나 이점은 무엇입니까? 어떤 상황에서 이런 방식으로 작업하면 좋을까요?

출처

2010-04-08 Myster

ViewModel의 용도보다 도메인 모델을 캡슐화하는 경우 – Omu

주된 이유는 제품, 바구니, 내비게이션 등 여러 도메인 모델을 모으는 것이 었습니다. – Myster

도메인 모델을 직접보기에 노출시키는 것은 본질적으로 나쁨이 아닙니다. 주요 위험은 Employee 객체의 급여 필드와 같은 의미가없는 속성을 노출하면 발생합니다. JSON을 반환하는 경우이 점을주의해야합니다.

또 다른주의 할 점은 편집 양식에서 다시 바인딩 할 때입니다. 관련된 risks에 대해 알고 있어야합니다. 기본적으로 악의적 인 사용자는 편집 가능한 것을 의미하지 않는 필드와 일치하는 필드를 POST에 추가 할 수 있습니다. 나는 항상 도메인으로 다시 매핑하기 전에 서비스에 전달되는 중간 객체에 바인딩합니다.

출처

2010-04-08 04:02:04 Ryan

이것은 동작하는 도메인 개체에만 적용됩니다 매개 변수; 보기를 전달하는 것에 대해 불안한 점은 없습니다. – queen3

@queen 두 가지 우려 사항이 있습니다. 나가는 것 : JSON/XML /을 통해 민감한 필드를 노출. 들어오는 것 : 악성 폼 매개 변수. – Ryan

viewModel을 옹호하는 누군가가 포스트 백을위한 Action 매개 변수와 동일한 유형임을 상기합니다. 이는 도메인 모델을 완전히 분리해야한다는 것을 의미합니다. (수정을 위해 전적으로 열리지 않는 한) – Myster

불량? Automapper를 사용할 수 없습니다. ;)

양호? 아무 것도 떠오르지 않습니다.

나는 당신이 끔찍한 일을했다고 생각하지 않습니다. 너에게 효과가 있니? 그렇다면 왜 그렇지 않습니까?

출처

2010-04-08 03:29:57 jfar

asp.net MVC는 View-Model을 도메인 모델로 캡슐화해야합니까?

답변

관련 문제