[SpringMVC] DTO 사용이유

DTO를 사용하는 이유

요청과 응답에 entity를 직접 사용하기 보다는 DTO를 사용하자.

//entity를 직접사용하는 예시
@PostMapping("/article/post")
public String postArticle(Article article) {
    articleService.post(article.toArticle());
    return "redirect:/";
}

//DTO를 직접 사용하는 예시
@PostMapping("/article/post")
public String postArticle(ArticleDTO articleDto) {
    articleService.post(articleDto.toArticle());
    return "redirect:/";
}

위의 예시처럼 domain대신 DTO를 사용하면 얻을수 있는 이점은 다음과 같다.

 

엔티티의 내부 구현을 캡슐화 할수 있다.

entity의 getter와 setter를 사용한다면 데이터 전달 역활을 수행할수 있을지도 모른다. 하지만 이런 방식으로 entity를 사용한다면 controller와 같은 비지니스 로직과 상관없는 곳에서 자원의 속성이 실수로 변경될수 있으며, 엔티티를 UI계층(MVC 패턴에서 view와 연관된 부분)에 노출하는 것은 보안상으로 바람직 하지 못하다.

 

필요한 데이터를 선별할 수 있다.

특정 API 요청에 필요한 데이터만 전송하면 네트워크를 통해 전송해야 하는 데이터의 양을 줄여 응답 시간을 단축할 수 있다.

 

순환참조를 예방할수 있다.

순환참조란(Circular reference) 서로 다른 두개 이상의 객체가 서로를 참조하는 형태를 말한다. 즉 객체 A가 객체 B를 참조하고, 동시에 객체 B가 객체 A를 참조하는것을 순한 참조하란다.

이런 순환참조가 발생한다면 객체A,B는 서로가 서로를 참조하는 형태이므로 GC의 수거 대상이 되지 않아 메모리 누수가 발생할수있다.

또한 객체A,B가 서로를 참조함으로써 무한히 반복되는 무한 루프가 발생할수 있다.

우리가 MVC 모델에서 response를 entity로 한다면 엔티티가 참조하고 있는 객체는 지연 로딩되고, 로딩된 객체는 또 다시 본인이 참조하고 있는 객체를 호출하게 된다. 이렇게 서로 참조하는 객체를 계속 호출하면서 결국 무한 루프에 빠지게 될수있다.

이러한 현상을 방지하기위해 response를 DTO로 두는것이 더 안전하다는 것이다.

 

validation 코드와 모델링 코드를 분리할수 있다.

엔티티 클래스는 DB와 관련된 비지니스 로직이 작성되있는 곳이다. 따라서 이곳에 validation을 위한 코드( ex) @NotNull)가 들어간다면 엔티티가 매우 복잡해질수 있다. 이러한 현상을 방지하기위해 validation을 DTO에서 정의한다면, 엔티티 클래스는 좀더 모델링과 비지니스 로직에만 집중할수 있다.

 

DTO를 사용한다면 어느 계층에서 사용하는것이 좋을까

사실 아직은 잘 모르겠다. 원칙적으론 DTO가 service layer에 들어오면 안되는거 같지만(여러 종류의 컨트롤러가 해당 서비스를 사용할수 없기 때문에) 현업에서는 여러 컨트롤러가 하나의 서비스를 사용하는 경우보단 하나의 컨트롤러가 서비스를 쓴다고한다.

🙏Reference

• DTO
• DTO