바인딩 도메인 모델이 나쁜 생각일까요?

Question

조치 방법에서 매개 변수로 모델을 직접 바인딩하는 것이 나쁜 생각으로 간주되는지 궁금합니다.

양식이 복잡 해지면 맞춤 모델 바인더를 만들 수 있습니다.

이 접근법을 사용하는 함정이 있습니까?

저는 가능한 한 단순한 응용 프로그램을 유지하고 싶기 때문에 viewmodel을 만드는 것을 피하고 싶습니다. 모델 바인딩에 코드와 모델 뷰를 복사하는 것을 피하고 싶습니다.

Answer 1

거의 항상보기 모델을 사용하는 것이 좋습니다.

기본 개체 템플릿을 사용하는 경우 ... 평면 모델이 좋지는 않지만 무시할 수는 있지만 항상 좋은 생각은 아닙니다. 도메인 모델은 일반적으로 평평하지 않습니다. 어느 쪽이든, ViewModel을 사용하면 ModelMetaData 기반의 모든 것이 더 쉽습니다.

좀 더 집중된 모델을 가지고 있기 때문에 ViewModel을 사용하는 것이 더 쉽습니다. 일부보기에서는 유효성 검사 만하는 경우도 있습니다.

ViewModels를 작성하면 JsonResult를 사용하여 모델을 보내는 것이 훨씬 더 안전합니다. 음 ... ViewModels를 사용하지 않아도 도메인 모델을 보내지 않아야합니다. 그러나 ViewModel을 준비 할 때 JsonResult를 사용하면 더 쉽습니다. 또한 실수로 도메인 모델을 사용하는 데 익숙해지면 중요한 정보를 쉽게 노출 할 수 있습니다.

도메인 모델의 속성을 변경해도 모든보기를 변경해야하는 것은 아니며 ViewModel의 작성을 변경하기 때문에 변경이 더 쉬운 경우가 있습니다 (어떤 종류의 매퍼를 사용하는 경우 하나뿐입니다. 바인딩으로 변경), 이것은 매우 강력한 포인트 IMO는 아니지만.

일부 다른 이점은 비즈니스 계층에서 프리젠 테이션 계층을 분리하는 것이며, EF 또는 비포 코 오브젝트를 사용하는 경우 뷰에서 사용하기가 더 어려울 것입니다.

코드 중복을 제거하려면 자동으로 ViewModel을 만드는 필터를 만드는 것이 좋으며 매퍼를 사용하는 액션 필터가 없어도 많은 코드 중복을 제거 할 수 있습니다.

나는 사용자 정의 모델 바인더를 만드는 것이 ViewModels를 사용하는 것보다 간단하다는 것을 알지 못합니다.

Answer 2

반드시 그렇지는 않습니다. 그러나 곧 모델에 있어야하지만 UI와 관련된 일부 상태를 찾을 것이고 어쨌든 ViewModel을 생성하게됩니다. 당신이 string로 정의해야하므로이 선택하기에 문제가 있기 때문에 DateTime로 정의 된 경우

또한 DateTime 같은 일부 속성에 대해,이 모델에서 잘 작동하지 않을 것입니다. 그리고 나는 당신이 날짜를 string에 넣고 싶지 않다고 생각합니다.

또한 DropDown 항목의 경우 모델에서 이해할 수없는 SelectListItem에 대한 모델 컬렉션이 필요합니다.

그게 나에게 일어난 일이야.

Answer 3

항상 ViewModel을 작성하는 것이 좋습니다. 가장 단순한 형태로는 단순히 도메인 객체 (및 액세서리 데이터)가있는 속성을 포함 할 수 있습니다.뭔가 같은 :

public class DomainModelClass 
{ 
    int Property1 { get; set; } 
    int Property2 { get; set; } 
} 

public class ViewModelClass 
{ 
    DomainModelClass DomainModel { get; set;} 

    SelecList List1 { get; set; } 
} 

어쨌든,이 제안은 당신이 "진짜"뷰 모델을 만들 조언 및 뷰 모델 < 매핑 AutoMapper 같은 것을 사용하는 것이 있기 때문에, 간단하게하기 위해 단지입니다 -> DomainModel를도에, 간단한 시나리오.