asp.net mvc-2의 한 페이지에서 부분 뷰를 강력하게 형식화해야 하나의 결합 된 뷰 모델이 있습니까?

Question

asp.net mvc-2에 대한 부분보기 및 모델보기에 대한 질문이 있습니다.

완전히 새로운 뷰 모델을 구현하지 않고 한 페이지에서 두 개의 강력한 형식의 부분 뷰를 가질 수 있는지 궁금합니다.

예를 들어 프로필을 표시하는 페이지가 있지만 빠른 연락처를 추가 할 수있는 인라인 양식이 있습니다. 이러한 엔티티에는 이미 자체보기 모델이 있습니다. 예를 들어 ProfileViewModel과 ContactViewModel이 있습니다.

내보기에는 두 개의 강력한 형식의 부분 뷰, 즉 ProfileViewModels의 IEnumerable 목록을 사용하는 뷰와 ContactViewModel을 사용하는 뷰가 필요합니다. ProfileViewModel 및 ContactViewModel의 목록을 보유하고있는이 페이지의 'IndexViewModel'이라는 세 번째 뷰 모델을 만들지 않도록하는 것이 바람직할까요? 이 뷰 모델을 나쁜 방식으로 구현하지 않거나 뷰 모델이 적어지기 때문에 좀 더 자세하게 구현할 수 있습니까?

감사합니다.

Answer 1

두 부분보기에 이미 정의 된보기 모델이 필요한 경우 해당 부분을 호스트하는 페이지는 어떻게 든보기 모델을 제공해야합니다. 연락 정보가 백엔드에서 도착하기 때문에 IEnumerable<ProfileViewModel>을 포함 페이지에 제공해야하는 방법을 쉽게 상상할 수 있습니다. ContactViewModel은 실제로 모든 데이터를 보유하고 있습니까? 그렇지 않은 경우에는 포함 된 페이지의보기에서 그 자리에서 바로 만들 수 있으며 IEnumerable<ProfileViewModel> 만 전달하면됩니다.

그렇지 않으면 포함 된보기에 IEnumerable<ProfileViewModel> 및 ContactViewModel이 모두 수신되어야합니다. 내가 향한 옵션은 실제로이 두 값에 대한 데이터 멤버가있는 새로운 뷰 모델을 정의하는 것입니다. 다소 더 잘 문서화되어 있으며 을 통해 값을 전달하는 것보다 더 나은 컴파일러 유형 검사를 허용합니다.

보기 모델을 만드는 것이 자질구레 한 개념입니다. 뷰 모델의 정의가 일부 백엔드 엔터티의 정의를 단순히 반영하는 경우 실제로 부분 뷰의 경우가 될 수 있습니다. 이 경우 뷰 모델에서 정의와 내용을 복제하는 대신 직접 백엔드 엔티티를 전달하는 것을 고려할 수 있습니다.

마지막으로보기 모델은 도구 일뿐입니다. 그들이 가치를 더하는 경우에 사용하십시오. 일부 응용 프로그램은 고유 한 뷰 모델 클래스를 사용하여 명확성, 문서화 및 느슨한 결합 이점을 얻습니다. 종종 작은 응용 프로그램을 사용하는 경우 오버 헤드가 발생하기에 충분하지 않습니다. 뷰 모델 (또는 다른 모든 디자인 패턴)을 구현하지 않는 것은 본질적으로 '나쁜 습관'이 아닙니다. 귀하가 합리적인 주장을하는 경우 편안함을 느낄 수있는 디자인 선택입니다.