내 도메인 개체를 유지하기 위해 NHibernate를 사용하고 있습니다. 단순하게 유지하기 위해 ASP.NET MVC 프로젝트를 프레젠테이션 레이어와 서비스 레이어로 사용하고 있습니다.
컨트롤러 클래스에서 XML로 도메인 개체를 반환하고 싶습니다. Stack Overflow에 대한 몇 가지 게시물을 읽은 후 DTO를 수집하는 것이 좋습니다. 그러나 ViewModel에 대한 게시물도 보았습니다.
내 질문 : 데이터 전송 개체와 ViewModel은 같은 것입니까? 아니면 ViewModel은 DTO의 일종의 하위 패턴입니까?
답변
DTO의 표준 정의는 동작이없는 개체의 데이터 모양입니다.
ViewModel은보기의 모델입니다. ViewModel은 일반적으로 하나 이상의 개체 (또는 DTO)의 전체 또는 부분 데이터와보기의 동작에 특정한 추가 구성원 (보기에서 실행할 수있는 방법,보기 요소를 전환하는 방법을 나타내는 속성 등)입니다. 뷰 모델을 뷰와 동작에 대한 모든 데이터로 볼 수 있습니다. ViewModel은 일대일 비즈니스 개체 또는 DTO에 매핑 할 수도 있고 매핑하지 않을 수도 있습니다.
그건 그렇고, NHibernate 프로젝션 은 특정 뷰 모델이 지속 된 객체의 데이터 하위 집합을 필요로하는 경우 유용합니다.
답변
ASP.NET MVC 사례의 ViewModel은 DTO와 동일하지만 MVVM의 ViewModel에는 동작이 있지만 DTO에는 없기 때문에 MVVM 패턴의 ViewModel은 DTO와 다릅니다.
답변
DTO! = ViewModel
에서 MVVM의 패턴의 ViewModel이보기에서 모델을 분리하는 데 사용됩니다. 모델을 표현하기 위해 간단한 DTO 클래스를 사용할 수 있으며 , 이는 NHibernate를 통해 다시 데이터베이스에 매핑됩니다. 하지만 DTO로 모델링 된 ViewModel 클래스를 본 적이 없습니다. ViewModel 클래스는 대부분 DTO에는없는 동작을 가지고 있습니다.
답변
DTO-데이터 전송 개체는 데이터 전송을위한 컨테이너라고 말한 그대로입니다. 그들은 동작이 없지만 단지 세터와 게터의 무리입니다. 어떤 사람들은 그것들을 불변으로 만들고 기존의 것을 업데이트하는 대신 필요할 때 새로운 것을 만듭니다. 유선을 통해 전송할 수 있도록 직렬화 할 수 있어야합니다.
일반적으로 DTO는 원격 서비스에 대한 호출이 비용이 많이들 수 있으므로 한 계층에서 다른 계층으로 데이터를 전송하는 데 사용됩니다. 따라서 필요한 모든 데이터가 DTO로 푸시되고 하나의 청크 (거친 단위)로 클라이언트로 전송됩니다.
그러나 일부 사람들은 화면 바운드 DTO의 개념을 사용합니다 (프로세스 경계를 넘어서는 것과 관련이 없음). 다시 이것들은 필요한 데이터 (일반적으로 특정 화면에 필요한 데이터이며 다양한 소스의 데이터 집합 일 수 있음)로 채워져 클라이언트로 전송됩니다.
http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx
이미 언급했듯이 간단한 경우에는이 DTO를 뷰에 바인딩하는 데 사용할 수 있지만 더 복잡한 경우에는 ViewModel을 생성하고 DTO에서 ViewModel로 데이터를 언로드해야합니다 (MVVM 패턴 적용시). .
다시 이미 언급했듯이 DTO! = ViewModel
과
DTO와 ViewModel은 삶의 목적이 다릅니다.
답변
첫째, 주요 차이점은 ViewModel이 DTO가하지 말아야 할 동작이나 메서드를 가질 수 있다는 것입니다.
둘째, ASP.NET MVC에서 DTO를 ViewModel로 사용하면 응용 프로그램이 DTO와 밀접하게 연결되며 이는 DTO를 사용하는 목적과 정반대입니다. 그렇다면 도메인 모델 또는 DTO를 사용하는 차이점은 무엇입니까? 안티 패턴을 얻기 위해 더 복잡합니까?
또한 ASP.NET의 ViewModel은 유효성 검사를 위해 DataAnnotations를 사용할 수 있습니다.
동일한 DTO는 서로 다른 ViewModel 매핑을 가질 수 있으며 하나의 ViewModel은 서로 다른 DTO에서 구성 될 수 있습니다 (항상 구성이 아닌 개체 매핑 사용). DTO를 포함하는 ViewModel이 있으면 더 나쁘다고 생각하기 때문에 동일한 문제가 발생합니다.
프레젠테이션 계층에서 DTO를 계약으로 생각하면 응용 프로그램에 대해 낯선 것으로 간주해야하며 제어 할 수없는 개체를 받게됩니다 (예 : 서비스, dto 및 프레젠테이션 계층이 있더라도 당신입니다).
마지막으로 이렇게 깔끔하게 분리하면 개발자가 쉽게 함께 작업 할 수 있습니다. ViewModels, Views 및 Controllers를 설계하는 사람은 다른 개발자가 구현을 완료하면 매핑을 만들기 때문에 서비스 계층이나 DTO 구현에 대해 걱정할 필요가 없습니다. 테스트 용 데이터가있는 프레젠테이션 레이어
답변
일부 간단한 뷰의 경우 DTO를 모델로 사용하지만 뷰가 더 복잡 해짐에 따라 ViewModels를 생성합니다.
나에게 그것은 신속 함 (DTO 사용)과 유연성 (ViewModel 생성은 더 많은 관심사 분리를 의미 함) 사이의 균형입니다.
답변
DTO를 ViewModel로 사용하는 경우 DTO를 변경하는 이유 때문에 DTO에 대한 의존도가 높으면 ViewModel에 영향을 미칠 수 있습니다.
DTO를 더 잘 사용하고 뷰 모델로 변환하십시오.
