‣

DTO를 사용하는 이유

• 유효성 검증을 DTO에서 실행하여 핸들러 메서드의 코드가 간결해진다.
• 요청의 여러 파라미터를 객체로 받을 수 있어 역시 코드가 간결해진다.
• HTTP 요청의 수를 줄일 수 있다.
  • 파라미터로 넘어온 값을 이곳저곳에 널어놓으면 찾기도 어렵고 필요한 경우 다시 받아와야 할 수도 있다. DTO에 저장해놓으면 해당 요청 동안 한 번만 값을 담아놓으면 된다. 참고
• 도메인과 데이터를 분리할 수 있다.
  • DTO를 사용할 때 보통 정적 팩토리 메서드 패턴을 사용해서 도메인 객체를 생성하여 DB와 통신한다. 또 DTO를 통해서 도메인과는 다른 뷰를 작성해서 리턴할 수도 있다. 이 경우 도메인은 DTO를 알 필요가 없다.
• 그럼에도 도메인에 대해 여러 객체가 생겨나게 되므로 의미없이 무분별하게 DTO를 생성하는 것은 좋지 않다. 다른 DTO를 재사용하거나, 트레이드오프를 잘 계산해야 한다. 재사용되지 않고 일회성으로만 사용되는 것도 옳지 않다.
• 또한 DTO는 단순히 데이터를 바인딩하고 옮기는 역할만을 하므로, 추가적인 비즈니스 로직을 포함시켜서는 안된다. 여기를 참고하자.

JSON으로 통신하기: @RequestBody와 @ResponseBody

<aside> 📌 @RequestBody와 @ModelAttribute

@RequestBody는 말 그대로 HTTP message의 body를 그대로 요청하겠다는 의미이다. 현대 웹 애플리케이션에서는 JSON으로 통신하는 경우가 대다수이기 때문에 사용된다. 요청에서 받은 body(JSON)는 HTTPMessageConverter에 의해 자바 객체로 매핑된다.

반면 @ModelAttribute 는 HttpSession에 등록된 ModelAttribute를 가져오거나 요청 URL로 넘어온 쿼리 파라미터를 매핑하는 데에 사용된다. 파라미터들을 객체로 매핑해주는 건 같지만, HTTP message body를 읽어오지는 못한다.

</aside>

• 핸들러 메서드의 리턴 타입에 대해서는 여기를 참고하자. (@ResponsBody나 ResponseEntity<T>, HttpEntity<T>가 리턴될 때에는 HttpMessageConverter의 구현체에 의해 응답을 만들어서 뷰로 리턴된다.)