최근에 사람들 은 DTO ( 데이터 전송 개체 )가 안티 패턴 이라고 말합니다 .
왜? 대안은 무엇입니까?
답변
일부 프로젝트에는 모든 데이터가 두 번 있습니다. 도메인 개체로 한 번, 데이터 전송 개체로 한 번
이 복제는 비용 이 많이 들기 때문에 아키텍처는 이러한 분리로부터 큰 이점을 얻을 수 있어야합니다.
답변
DTO는 안티 패턴이 아닙니다. 유선으로 데이터를 전송하는 경우 (예 : Ajax 호출의 웹 페이지로) 대상이 사용할 데이터 만 전송하여 대역폭을 절약해야합니다. 또한 프리젠 테이션 계층이 데이터를 기본 비즈니스 오브젝트와 약간 다른 형식으로 갖는 것이 편리한 경우가 종종 있습니다.
나는 이것이 Java 지향 질문이라는 것을 알고 있지만 .NET 언어에서는 익명 유형, 직렬화 및 LINQ를 사용하여 DTO를 즉석에서 구성 할 수 있으므로 DTO를 사용하여 설정 및 오버 헤드를 줄일 수 있습니다.
답변
EJB 3.0의 안티 패턴 DTO는 다음과 같이 말합니다.
EJB 3.0 이전의 EJB 사양에서 Entity Beans의 무거운 특성으로 인해 DTO (Data Transfer Objects)와 같은 디자인 패턴이 사용되었습니다. DTO는 티어를 통해 데이터를 전송하는 데 사용되는 경량 오브젝트 (처음에는 엔티티 Bean이어야 했음)가되었습니다. 이제 EJB 3.0 스펙은 엔티티 Bean 모델을 POJO (Plain old Java Object)와 동일하게 만듭니다. 이 새로운 POJO 모델을 사용하면 더 이상 각 엔티티 또는 엔티티 세트에 대해 DTO를 작성할 필요가 없습니다. 계층 전체에 EJB 3.0 엔티티를 보내려면 java.io.Serialiazable을 구현하십시오.
답변
DTO는 반 패턴 그 자체가 아니라고 생각하지만 DTO 사용과 관련된 반 패턴이 있습니다. Bill Dudney는 DTO 폭발을 예로 들어 설명합니다.
http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf
여기에 언급 된 여러 DTO 남용이 있습니다.
http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/
계층간에 데이터를 전달하는 수단으로 3 계층 시스템 (일반적으로 EJB를 기술로 사용) 때문에 시작되었습니다. Spring과 같은 프레임 워크를 기반으로하는 대부분의 현대 Java 시스템은 POJO를 단일 계층에서 도메인 오브젝트 (종종 JPA 등으로 주석이 달린 등)를 사용하여 단순화 된 대체보기를 사용합니다. 여기에서 DTO를 사용할 필요는 없습니다.
답변
OO 순수 주의자들은 객체가 실제 도메인 객체 대신 데이터 테이블 표현이되기 때문에 DTO가 반 패턴이라고 말한다.
답변
답변
분산 시스템을 구축하는 경우 DTO는 반 패턴이 아닙니다. 모든 사람이 그런 의미로 발전하는 것은 아니지만 Open Social 앱 (예를 들어)이 모두 JavaScript로 실행되는 경우입니다.
API에 많은 양의 데이터를 게시합니다. 그런 다음 일부 형태의 객체, 일반적으로 DTO / 요청 객체로 역 직렬화됩니다. 그런 다음 모델 개체로 변환하기 전에 입력 한 데이터가 올바른지 확인하기 위해 유효성을 검사 할 수 있습니다.
제 생각에는 잘못 사용되어 반 패턴으로 간주됩니다. 분산 시스템을 구축하지 않으면 시스템이 필요하지 않을 가능성이 있습니다.
