[java] REST API-DTO? [닫은]

REST API에서 DTO를 사용해야하는 이유

DTO는 약자에 대한 D ATA T 를 ransfer O bject .

이 패턴은 웹 서비스 처럼 원격 인터페이스 로 데이터를 전송 하는 매우 잘 정의 된 목적으로 만들어졌습니다 . 이 패턴은 REST API에 매우 적합하며 DTO는 장기적으로 더 많은 유연성 을 제공합니다 .

애플리케이션 의 도메인 을 나타내는 모델과 API 가 처리 하는 데이터 를 나타내는 모델은 서로 다른 관심사 이며 서로 분리 되어야합니다 . 애플리케이션 도메인 모델에서 필드를 추가, 제거 또는 이름을 바꿀 때 API 클라이언트를 중단하지 않으려 고합니다.

서비스 계층은 도메인 / 지속성 모델에서 작동하지만 API 컨트롤러는 다른 모델 집합에서 작동해야합니다. 예를 들어, 도메인 / 지속성 모델이 새로운 비즈니스 요구 사항을 지원하도록 발전함에 따라 이러한 변경을 지원하기 위해 새 버전의 API 모델을 만들 수 있습니다. 새 버전이 출시 될 때 이전 버전의 API를 더 이상 사용하지 않을 수도 있습니다. 그리고 사물이 분리 될 때 완벽하게 달성 할 수 있습니다.

---

퍼시스턴스 모델 대신 DTO 노출의 몇 가지 이점을 언급하면 ​​다음과 같습니다.

• API 모델에서 지속성 모델을 분리 합니다.

• DTO는 필요에 맞게 조정할 수 있으며 지속성 엔터티의 특성 집합 만 노출 할 때 유용합니다. 당신은 같은 주석이 필요하지 않습니다 @XmlTransient및 @JsonIgnore일부 속성의 직렬화를 방지 할 수 있습니다.

• DTO를 사용하면 지속성 엔터티 에 주석 이 포함되지 않습니다. 즉, 지속성 엔터티에 비 지속성 관련 주석이 포함되지 않습니다.

• 당신은해야합니다 모든 권한 을 만들거나 자원을 업데이트 할 때 당신이 받고있는 속성 이상을.

• 당신이 사용하는 경우 자신감을 , 당신은 사용할 수 있습니다 @ApiModel및 @ApiModelProperty주석 당신의 영속 엔티티를 엉망으로하지 않고 API 모델을 문서화 할 수 있습니다.

• 각 버전의 API마다 다른 DTO를 가질 수 있습니다.

• 관계를 매핑 할 때 유연성이 향상됩니다.

• 미디어 유형마다 다른 DTO를 가질 수 있습니다.

• DTO는 HATEOAS에 대한 링크 목록을 가질 수 있습니다 . 그것은 영속 객체에 추가해서는 안되는 종류입니다. 사용하는 경우 봄 HATEOAS을 , 당신은 당신의 DTO 클래스를 확장 할 수 있습니다 RepresentationModel(이전으로 알려진 ResourceSupport) 또는로 포장 EntityModel(이전으로 알려진 Resource<T>).

상용구 코드 다루기

지속성 엔터티를 DTO에 매핑하거나 그 반대로 수동 으로 매핑 할 필요는 없습니다 . 이를 위해 사용할 수 있는 많은 매핑 프레임 워크 가 있습니다. 예를 들어 주석 기반이며 Maven Annotation Processor로 작동하는 MapStruct를 살펴보십시오 . CDI 및 Spring 기반 애플리케이션 모두에서 잘 작동합니다.

또한 getter, setter , 및 메소드 를 생성 하기 위해 Lombok 을 고려할 수도 있습니다.equals()hashcode()toString()

---

^{관련 : DTO 수업에 더 나은 이름을 부여하려면이 답변을 참조하십시오 .}

---

답변