• DTO란

  DTO(Data Transfer Object)란 계층간 데이터 교환을 위해 사용하는 객체(Java Beans)이다.

• DTO의 사용

  • DTO를 사용하지 않는 경우

    public class User {
    
      private Long id;
      private Sting name;
      private String email;
      private String password;
      ...
    }
    

    @GetMapping("/page/{id}")
    public ResponseEntity<User> viewMyPage(@PathVariable("id") Long id) {
        return ResponseEntity.ok(userService.viewMyPage(id));
    }
    

    이렇게 응답으로 도메인 Model인 User를 넘겨주면 다음와 같은 문제점이 있다.

    1. 도메인 Model의 모든 속성이 외부에 노출된다.
       • 위 예시의 경우 사용자가 마이페이지 조회에 대한 요청을 하는데 그에 대한 응답으로 외부에 노출되면 안되는 'password' 데이터까지 응답해준다. 이처럼 도메인 Model 자체를 응답해주면 중요한 정보가 외부에 노출되는 보안 문제가 발생한다.
       • 또한 View에서 보낸 요청에 대한 데이터 외의 불필요한 데이터를 모두 가지고 있다.
    2. UI 계층에서 Model의 메소드를 호출하거나 상태를 변경시킬 위험이 존재한다.
    3. Model과 View가 강하게 결합되어, View의 요구사항 변화가 Model에 영향을 끼치기 쉬워진다.
       • 또한 User Entity의 속성이 변경되면, View가 전달받을 JSON 등 클라이언트의 코드에도 변경을 유발하기 때문에 상호간 강하게 결합된다.

  • DTO를 사용하는 경우

    public class UserResponseDto {
      private String name;
      private String email;
    }
    

    @GetMapping("/page/{id}")
    public ResponseEntity<UserResponseDto> viewMyPage(@PathVariable("id") Long id) {
        return ResponseEntity.ok(userService.viewMyPage(id));
    }
    

    DTO를 사용하면 앞에서 언급했던 문제들을 해결할 수 있다. 도메인 Model을 캡슐화하고, UI 화면에서 사용하는 데이터만 선택적으로 보낼 수 있다.

• DTO의 사용범위

  • 데이터 전달 객체인 DTO를 비즈니스 로직 수행을 위해 Domain(Entity) 객체로 변환 수행을 어디에서 해야하나?

    1. Controller 와 Service 단의 Domain(Entity) 통신

       DTO ↔ Domain(Entity) 객체 변환을 Controller 에서 담당

       @PostMapping("/article")
       public ResponseEntity<ArticleResponseDto> saveArticle(@AuthenticationPrincipal LoginUser loginUser, @RequestBody ArticleRequestDto articleRequestDto) {
       	Tags tags = tagService.findTagsByTagColor(articleRequestDto.getTagColor());
       	List<History> history = loginUser.findFormerHistories(tags);
       	Article article = new Article(articleRequestDto.getId(), articleRequestDto.getName(), articleRequestDto.getContent(), tags, history);
       	
       	Article savedArticle = articleService.createArticle(article);
       
       	return ResponseEntity.ok(ArticleResponseDto.from(savedArticle));
       }
       

       public Article createArticle(Article article) {
       	return articleRepository.save(article);
       }
       

       • 문제점

         • View에 반환할 필요가 없는 데이터까지 Domain 객체에 포함되어 Controller(표현 계층)까지 넘어옵니다.
         • Controller가 여러 Domain 객체들의 정보를 조합해서 DTO를 생성해야 하는 경우, 결국 Service 로직이 Controller에 포함되게 됩니다.
         • 여러 Domain 객체들을 조회해야 하기 때문에 하나의 Controller가 의존하는 Service의 개수가 비대해집니다.

         복잡한 어플리케이션의 경우 여러 Service를 통해 부수적인 정보들을 조회하여 Domain 객체를 구성할 수 있는 경우도 존재하기 때문에 Controller가 View에서 전달받은 DTO만으로 Entity를 구성하기가 어려움.

    2. Controller 와 Service 단의 DTO 통신

       DTO ↔ Domain(Entity) 객체 변환을 Service 에서 담당

       @PostMapping("/article")
       public ResponseEntity<ArticleResponseDto> saveArticle(@AuthenticationPrincipal LoginUser loginUser, @RequestBody ArticleRequestDto articleRequestDto) {
       	ArticleResponseDto articleResponseDto = articleService.createArticle(loginUser, articleRequestDto);
       
       	return ResponseEntity.ok(articleResponseDto);
       }
       

       public ArticleResponseDto createArticle(LoginUser loginUser, ArticleRequestDto articleRequestDto) {
       	Tags tags = tagService.findTagsByTagColor(articleRequestDto.getTagColor());
       	List<History> history = loginUser.findFormerHistories(tags);
       	Article article = new Article(articleRequestDto.getId(), articleRequestDto.getName(), articleRequestDto.getContent(), tags, history);
       	
       	Article savedArticle = articleService.createArticle(createArticle);
       
       	return ArticleResponseDto.from(savedArticle);
       }
       

References

https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/ https://velog.io/@minide/Spring-boot-DTO의-사용-범위 https://kafcamus.tistory.com/13 https://kafcamus.tistory.com/12 https://cheolhojung.github.io/posts/record/jpa-entity-vs-dto.html