우리는보기에서 도메인 개체를 사용할 것인지 (asp.net mvc 2) 사용할지 또는 데이터에 ViewModel을 보내야하는 모든보기를 사용해야하는지에 대한 논의가있었습니다.보기의 도메인 개체
누구든지이 주제에 찬성/반대 의견이 있었는지 궁금 해서요. 가장 가능성이 암갈색 작업을 직렬화, 프록시 될 것입니다 도메인 개체 - 당신이 NHibernate에 또는 유사한을 사용하는 경우
는내 조회와 도메인 개체를 분리하고 싶습니다. 지금까지 내 도메인 객체는 응용 프로그램의 도메인을 나타내는 목적으로 만 사용되었으며 이제는 응용 프로그램이 어떻게 표시되는지에 관해서도 우려하고 있습니다.
프리젠 테이션 계층에는 도메인 로직이 없어야합니다. 그들이 표시하는 모든 것은 컨트롤러가 미리 결정해야합니다. 이것을 확실히하는 이상적인 방법은, 뷰가 이러한 평탄화 된 ViewModel만을받는 것을 보증하는 것입니다.
나는 similar question 나에게 물어 보았다. 내가 프리젠 테이션 계층보다 도메인에있는 다른 디자인을 가진 에 장점이 있다고 생각
: 여기 허용 대답에서 인용합니다. 개념적으로 실제로 두 개의 다른 모델을 보면 은 도메인 계층이고 다른 하나는 표현 계층입니다. 모델의 각 모델은에 최적화되어 있습니다. 내가
Customer>Sales>Dispatch Address의 도메인 객체가있는 경우
, 나는 내보기에서 객체 탐색과 거래를해야하고 싶지 않아요. 모든 속성을 포함하는 병합 된 뷰 모델을 만듭니다. 훌륭한 오픈 소스 프로젝트 인 AutoMapper을 사용하면이 평평한보기/프리젠 테이션 모델로 매핑하는 데 별도의 작업이 거의 필요 없습니다.
해당 모델의 표현을 만들 수 있다면 왜 전체 도메인 개체를 다시보기로 전달 하시겠습니까?
감사드립니다. 항상 ViewModel을 사용하고 도메인 객체를 뷰 모델 내의 DTO에 매핑해야합니다. 여기서 바로 가기를 사용하지 마십시오. 컨벤션을 설정하면 나중에 겪을 고통을 완화 할 수 있습니다.
이유는 표준 패턴입니다.
w : //
에 따라 다릅니다. 어떤 경우에는 모델 클래스의 인스턴스를 사용하는 것이 좋습니다. 다른 경우에는 별도의 ViewModel이 더 나은 선택입니다. 내 경험에 의하면 귀하의 도메인 및 귀하의 견해에 다른 모델을 가지고있는 것이 완벽하게 허용됩니다. 또는보기에서 도메인 모델을 사용합니다. 가장 잘 맞는 것은 당신을 위해하십시오. 각 옵션에 대해 스파이크를 수행하고 작동하는 것을 확인한 다음 결정하십시오. 각보기 (및/또는 부분)마다 다른 옵션을 선택할 수도 있습니다.
모든 레이어에서 동일한 모델을 사용하는 것이 간단한 간단한 앱이 될 것입니다. 일반적으로 데이터 앱에 비해 양식이 거의 없습니다. 그러나 적절한 도메인의 경우 주제에 대한 내 생각은 변경 될 때 서로에게 영향을 미치지 않기 때문에 도메인 모델과 뷰 모델을 별도로 유지하는 것입니다.
백엔드에서 새로운 비즈니스 로직을 처리하기 위해 도메인 로직을 약간 변경해야하는 경우보기를 변경하지 않아도됩니다. 반대로 마케팅이나 누군가가보기를 변경하려는 경우 해당 변경 사항이 도메인으로 다시 유출되는 것을 원하지 않습니다 (필드를 채우고 일부보기 이외의 목적으로 데이터를 유지하지 않으면 어딘가에서이를 사용하게됩니다).
다른 접근 방식을 사용하는 두 개의 프로젝트에서 작업 중이므로 지금은 비교가 잘됩니다. 나는 이것이 "나쁜 것이고 이것은 좋은 것"이라고 말하는 것과는 거리가 멀다. 왜냐하면 이것은 어떤 패턴으로 쓰여졌 기 때문이다. 나는 패턴을 알고, 나는 패턴을 좋아하지만, 나는 그저 맹목적으로 옳은 것을 결코 따라하지 않습니다. 나는 항상 현재 목표를 달성하기 위해 현재 필요한 것을 사용합니다.
첫 번째 앱에서는보기에 도메인 개체를 사용하여 개발이 매우 빠릅니다. 몇 군데는 거의 변경되지 않고 추가 속성, 양식 입력 등이 있습니다. 레이어에 대해 신경 쓰지 않고 코드를 확장/변경하고 다른 문제로 넘어갑니다.
두 번째 앱에는 항상 여기에 사용되는 개체가있는 곳과 다른 곳에서 동일한 개체를 동일하게 찾고 동일한 작업을 수행하는 수십 개의 클래스가 있으며 동일한 개체의 다양한 버전간에 많은 변환 코드가 있습니다. 더 나쁜 점은 일부 개발자는 "이 버전"의 클래스에서 일부 로직을 수행하고 다른 로직은 "해당 버전"에서 수행된다는 것입니다. 개발은 매우 고통스럽고 나중에 많은 테스트가 필요합니다. 간단한 일을 변경하려면 많은주의가 필요하며 많은 코드를 변경해야합니다. 나는 작년에 적어도이 접근 방식으로 인해 비즈니스 이점을 보지 못했기 때문에이 앱이 마음에 들지 않았습니다. (그리고 우리는 올해부터 생산 단계에 있습니다.) 이 응용 프로그램은 개발 및 유지 보수 비용이 처음 것보다 3 ~ 4 배 더 비쌉니다.
그래서, 내 재미있는 대답은 : 그것은 다릅니다. 10-20 명으로 구성된 팀에서 일하면, 직장에 들어가고, 커피를 마시지 않고, 친구와 이야기하고, 간단한 일을하고, 집에 돌아 가기를 원합니다. 많은 중간 물체와 전환 코드가 도움이 될 것입니다. 목표가 빠르고 저렴하기를 원한다면 소프트웨어 비즈니스에 손을 대고 프로젝트를 현금화하려면 비즈니스 계층, 새로운 기능, 빠른 변경 등에 초점을 맞추고 싶을 것입니다 (우리는이 모든 것을 최종적으로 판매합니다. 맞습니까?) 두 번째 방법은 아마도 더 좋을 것입니다.
+1하지만 ID와 라벨 만있는 카테고리와 같은 간단한 도메인 개체는 어떻게됩니까? 이것들이 많은 응용 프로그램의 경우 MyEntity {Id, Label}와 MyDto {Id, Label}을 만드는 것은 상당히 짜증나게됩니다. 유일한 차이점은 이름입니다. – mathieu
@mathieu - 분명히 당신은 다음과 같은 예를 들어 볼 때 자신의 재량권을 사용할 수 있습니다. :). 귀하의 예와 같은 도메인 객체는 도메인 로직을 포함하지 않으므로 수용 할 수 있습니다. – GenericTypeTea
그게 내가 생각한거야. 만약 당신이 시간이 좀 있으면, 이것 좀 봐 줄래 : http://stackoverflow.com/questions/3539108/asp-net-mvc-model-inheritance? 난 정말 asp.net mvc 기술적 인 물건으로 새로운 아니지만, "철학적"및 디자인을 위해, 나는 몇 가지 포인터를 사용할 수 있습니다! – mathieu