DTO (Data Transfer Objects)를 사용하는 요점은 무엇입니까?

132

DTO 사용의 요점은 무엇이며 오래된 개념입니까? 뷰 레이어에서 POJO를 사용 하여 데이터를 전송하고 유지합니다. 이러한 POJO를 DTO의 대안으로 간주 할 수 있습니까?

java design-patterns

10

그러나 POJO는 DTO가 될 수 있고 DTO는 POJO로 구현 될 수 있습니다. 당신은 비교 사과와 오렌지입니다.

— Euphoric

3

좋은 아이디어가 구식이되는 이유는 무엇입니까? Lisp를보십시오. 농담 외에도 Euphoric에 동의합니다. 일반적으로 POJO를 사용하여 DTO를 구현합니다. 나는 여전히 DTO가 매우 간단하고 유용한 개념이라는 것을 알았습니다.

— Giorgio

요점은 없습니다. 반 패턴입니다. 데이터 전송 객체는 수치입니다

— yegor256

115

DTO는 패턴이며 구현 (POJO / POCO)에 독립적입니다. DTO에 따르면 원격 인터페이스에 대한 각 호출은 비용이 많이 들기 때문에 각 호출에 대한 응답은 최대한 많은 데이터를 가져와야합니다. 따라서 특정 작업에 대한 데이터를 가져 오는 데 여러 요청이 필요한 경우 가져올 데이터를 DTO에 결합하여 하나의 요청 만 필요한 모든 데이터를 가져올 수 있습니다. Enterprise Application Architecture의 패턴 카탈로그에 자세한 내용이 있습니다.

DTO는 구식이 아닌 기본 개념입니다.

— theD
소스

9

모두가 요즘 바퀴를 재발 명하는 것처럼 보이기 때문에 다른 이름으로 찾을 수 있습니다.

— linkerro

3

"값 개체"와 같습니다.

— theD

2

@linkerro : 사실 : 많은 사람들이 스스로 발명하지 않고 이미 발명 된 내용을 읽는 데 더 많은 시간을 소비해야한다고 생각합니다. 재발 명 된 물건은 항상 덜 성숙합니다.

— Giorgio

10

@Giorgio 아직 아이디어가 없었던 수많은 개발자들이 있습니다. 더 많은 개발자들이 그들이 읽는 모든 아이디어에 의문을 갖기를 바랍니다.

— Erik Reppen

59

개념으로서의 DTO (서버가 클라이언트에 반환 할 데이터를 수집하는 목적을 가진 개체)는 확실히 구식이 아닙니다.

무엇 이다 다소 시대에 뒤 떨어진 것은 전혀 논리를 포함하지 DTO들을 가지고있는 개념이며, 사용되는 경우에만 데이터를 전송하고 클라이언트에 전송하기 전에 도메인 개체에서 "매핑", 디스플레이 층에 전달하기 전에 모델을 볼 수 있습니다 매핑. 간단한 응용 프로그램에서는 도메인 개체를 DTO로 직접 재사용하고 표시 계층으로 직접 전달할 수 있으므로 통합 된 데이터 모델이 하나만있을 수 있습니다. 보다 복잡한 응용 프로그램의 경우 전체 도메인 모델을 클라이언트에 노출하지 않으려는 경우 도메인 모델에서 DTO 로의 매핑이 필요합니다. DTO에서 데이터를 복제하는 별도의 뷰 모델을 갖는 것은 거의 의미가 없습니다.

그러나이 개념이 단순한 잘못이 아닌 구식이되는 이유는 도메인 및 뷰 모델이 POJOS가 아니고 대신 프레임 워크에 직접 연결되어 있기 때문에 일부 (주로 오래된) 프레임 워크 / 기술에 필요하기 때문입니다.

EJB 3 표준 이전의 J2EE의 Entity Bean은 POJO가 아니며 대신 앱 서버에 의해 생성 된 프록시 객체였습니다. 클라이언트로 전송할 수 없었기 때문에 별도의 DTO 계층을 가질 수 없었습니다. -필수였습니다.

— 마이클 보그 워드
소스

2

UI 개발자가보다 일반적인 역할을 강요하면서 코드베이스 stupifying에서 Mapper.Map 현상을 분명히 발견했습니다. 왜 DTO가 그 자체를 매핑 할 수 없습니까?

— Erik Reppen

1

@ErikReppen 주요 이점은 도메인 모델과 DTO를 분리하는 것입니다. DTO가 자체 매핑하는 경우 도메인 모델에 대한 참조가 필요합니다.

— Alexander Derck

17

DTO는 구식 패턴이 아니지만 불필요하게 적용되어 구식으로 보일 수 있습니다.

Java Enterprise 커뮤니티에서 가장 잘못 사용 된 패턴은 DTO입니다. DTO는 배포 문제에 대한 솔루션으로 명확하게 정의되었습니다. DTO는 프로세스 (계층) 사이에서 데이터를 효율적으로 전송하는 대략적인 데이터 컨테이너를 의미했습니다. ~ 아담 비엔

예를 들어 JSF ManagedBean이 있다고 가정하십시오. 일반적인 질문은 Bean이 JPA 엔티티에 대한 참조를 직접 보유해야하는지 또는 나중에 엔티티로 변환되는 일부 중간 오브젝트에 대한 참조를 유지해야하는지입니다. 이 중개 오브젝트를 DTO라고 들었지만 ManagedBeans 및 엔티티가 동일한 JVM 내에서 작동하는 경우 DTO 패턴을 사용하면 이점이 거의 없습니다.

Bean Validation 어노테이션을 고려하십시오. JPA 엔티티는 @NotNull 및 @Size 유효성 검증으로 주석이 달릴 수 있습니다. DTO를 사용하는 경우 원격 인터페이스를 사용하는 클라이언트가 기본 유효성 검사에 실패했음을 확인하기 위해 메시지를 보낼 필요가 없도록 DTO에서 이러한 유효성 검사를 반복해야합니다. DTO와 엔티티 사이에 Bean Validation 주석을 복사하는 모든 추가 작업을 상상해보십시오.보기 및 엔티티가 동일한 JVM 내에서 작동하는 경우이 추가 작업을 수행 할 필요가 없습니다. 엔티티를 사용하십시오.

IAmTheDude의 엔터프라이즈 응용 프로그램 아키텍처 패턴 카탈로그에 대한 링크 는 DTO에 대한 간결한 설명을 제공하며 여기에 더 많은 참고 자료가 있습니다.

— 데이비드
소스

3

"... 그러나 ManagedBeans 및 엔티티가 동일한 JVM 내에서 작동하는 경우 DTO 패턴을 사용하면 이점이 거의 없습니다" 라는 문장이 있습니다 . DTO 패턴을 어리석게 구현하는 회사에는 중간 규모의 많은 앱이 있습니다. 쓸모없는 "복사 레이어"만 추가합니다. 이러한 시스템을 만든 사람들은 Java EE 5+ 엔터티 관리자가 트랜잭션이 끝날 때 엔터티를 분리하여 실제 DTO로 만드는 것을 알지 못했습니다. 따라서 단일 JVM 웹 애플리케이션의 경우 패턴 종류가 오래되었습니다 . J2EE 백엔드 개발자의 유물 것 같다 ...

— Kawu

그러나 "JSF ManagedBean"과 "JPA 엔티티"란 무엇입니까? 구식이 아닌 경우 프레임 워크 및 언어에 관계없이 용어를 사용하여 설명 할 수 있어야합니다.

— U Avalos

8

절대적으로하지! 최근에 나는 귀하가 사용하는 비즈니스 객체 (ORM 매퍼에 바인딩 된 것)보다는 DTO를 더 잘 사용하는 방법에 대한 교훈을 얻었습니다 .

그러나 좋은 패턴 책에 언급되어 있기 때문에 사용하기에 적합하지 않고 사용하기에 적합 할 때 사용하십시오.
내 마음에 오는 전형적인 예는 타사에 어떤 종류의 인터페이스를 노출시킬 때입니다. 이러한 시나리오에서는 교환 된 객체를 상당히 안정적으로 유지하여 일반적으로 DTO로 훌륭하게 달성 할 수 있습니다.

— 주리
소스

1

DTO가 특히 유용한 것으로 확인한 한 곳은 API 응답에 대한 논리를 포함하는 것입니다. 이 패턴을 사용하면 개체에서 다양한 형식으로 다양한 유형의 응답을 테스트 가능한 방식으로 쉽게 관리 할 수 있습니다. 현재 역할에서이 패턴을 사용하여 스택이 다양한 클라이언트 (http / mobile)에서 더욱 동형화되어 왔기 때문에 귀중한 API의 응답 형식 테스트를 시작할 수있었습니다. 확실히 구식이 아닙니다.

— 즈퀸 타나
소스