DTO 사용 이유

1.엔티티 내부 구현을 캡슐화

---

DTO 대신 domain 모델을 계층간 전달에 사용하면, UI 계층에서 도메인 모델의 메소드를 호출하거나 상태를 변경시킬 수 있다. 즉, DTO를 사용하여 domain 모델을 캡슐화 하여 보호할 수 있다. 또한 domain 모델을 계층간 전송에 사용하면 model과 view의 결합이 강해질 수 있다. view의 요구사항 변화로 domain의 코드를 변경해하는 일이 생길 수 있다. 

 

2.필요한 데이터를 선별

---

요청과 응답으로 Entity를 사용한다면, 요청하는 화면에 필요하지 않은 속성까지도 함께 보내지게 된다.

예를 들어 USER의 ID만 보여주면 되는 상황에서 USER가 가지고 있는 다른 값들까지 데이터에 포함 되는 것이다.

이처럼 원하지 않은  API 요청과 응답에서 Entity의 모든 값이 함께 전송되기 때문에 속도 또한 느려진다.

물론 Entity에서 @JsonIgnore 사용하여 화면으로 보내지 않을 값을 지정할 수 있지만 근본적인 해결책이 될 수는 없다.

그 이유는

1)어떤 값이 reponse되고 어떤 값이 ignore되는 지 알아보기 힘들다.

2)USER의 필요한 값을 다양한 API에 따라서 동적으로 선택할 수 없다.

 

3. 순환 참조 예방

---

JPA로 개발할 경우, 양방향 참조를 사용했다면 순환참조를 조심해야한다.

이 때, 양방향 참조된 Entity를 Controller에서 response로 return하게 되면, Entity가 참조하고 있는 객체는 지연 로딩되고, 로딩된 객체는 다시 본인이 참조하고 있는 객체를 호출하게 된다. 이렇게 객체가 서로 참조하며 계속 호출하면서 무한 루프 문제가 발생한다.

양방향 참조의 문제점이긴 하지만  양방향 참조를 꼭 사용해야하는 상황이라면 순환참조가 일어나지 않도록 응답의 return으로 DTO로 하면 조금 더 안전하다고 할 수 있다.

 

4.validation 코드와 modeling 코드를 분리할 수 있음

---

Entity 클래스는 DB의 테이블과 매칭되는 필드가 속성으로 선언되어 있고, 관련 비즈니스 로직이 작성된다.

그래서, 속성에는 @Column, @JoinColumn , @ManyToOne 등의 모델링을 위한 코드가 추가된다.

이 Entity에 @NotNull, @NotBlank 등과 같은 validation코드가 들어간다면 Entity클래스는 가독성이 떨어진다.

이때,  validation코드를 DTO에서 정의한다면, 엔티티 클래스를 모델링과 비즈니스 로직에만 집중되도록 역할을 분리하여 만들 수 있다.