DTO 너 왜 티오?

DTO를 왜 사용하는가?

일단 DTO에 대한 근본적인 의문부터 해결해보도록 하겠다.

DTO, Data Transfer Object는 데이터를 이동시키기 위한 객체이다.

DTO는 데이터를 전송하기 위한 객체이다.

DTO를 쓰는 이유를
"DTO를 쓰지 않고 하나의 객체를 데이터 전송 수단으로 사용하면 그럼 뭐가 나쁘냐?!"
로 바꿔서 생각해보도록 하겠다.

• 하나의 객체가 Controller와 Service를 거쳐 Repository까지 가서 저장하고~ 다시 Service를 거쳐 Controller에 전송하면~ 뭐가 문제일까?

이유는 다음처럼 몇 가지를 들 수 있다.

• 보안에 취약하다.
  - User 객체를 예로 들어보자. 만약, User 객체를 데이터 전송 수단으로 생각하고, 이를 View 단에 던져주면, User 안에 들어있는 password 필드까지 같이 넘겨주게 된다! 그러면 노출되지 않아야 할 정보들까지 모두 노출될 위험이 있다!
• 스프링 3계층(Controller/Service/Repository) 간 전송할 때 데이터가 변환될 위험이 있다.
  - 해당 경우에는 객체의 setter가 열려있을 위험이 있다. 이는 DB 혹은 Client에서 온 데이터임을 명확히 증명하기 어렵다. 왜냐? DB를 쓰는 이유는 무결성을 지키기 위함이지 않느냐!
• Client에 굳이 굳이 ~ 전달하지 않아도 되는 데이터가 포함된다.
  - 대표적으로,, 시스템이 활용하는 시스템 Column들이 있다. (createdAt, updatedAt) => 이렇게 클라이언트가 필요하지 않는 정보들을 넘겨주게 되면, Body만 커지고,, 이는 네트워크 비용만 올라가게 되고,,, 보안에 좋지 않다...
• 클라이언트가 필요한 데이터가 포함되지 않는다.
  - 예로, 구현코드 상 연관관계는 없지만, 화면에는 같이 뿌려져야 하는 경우가 있다!
  DB에는 생년월일을 저장하고 있는데, 화면에는 나이를 계산하여 출력해야 하는 경우가 있을 수 있다!
  백엔드 단에서 연산을 하고 클라이언트에 전송하는 것이 가장 바람직하다!

이렇게 DTO의 존재이유에 대해서 알아보았다.

그럼!

DTO 변환은 과연 어디서 동작해야 하나?

View에 원하는 정보'만'을 보내주기 위한 용도로 DTO를 사용한다.

이 DTO를 어디까지 끌고 올 수 있을까?

두 가지 의견이 나올 수 있을 것 같다.

1. 책임관계를 생각해보자. DTO는 결국 view에 전달해주고 view에서 필요한 정보를 가진 객체이다.
   이는, 아래 스프링 3요소의 흐름 상 Controller만 알게 하는 것이 가장 바람직하다! 더 깊게 (Service나 Repository까지) DTO를 인식시킬 필요가 없다!

View -> Controller -> Service -> Repository

2. DTO <-> Entity 변환은 연산 과정이라고 생각할 수 있다. 스프링에서 연산을 하는 곳은 Service단이다. 결국 Service가 해당 연산을 하도록 만드는 것이 바람직하다!

이 둘 중 나는 두 번째 의견에 가깝다.
첫 번째도 DTO를 View에 전달하기 위한 객체로만 인식한 후, 이를 생성해내는 것을 Controller에서 하게 만드는 것 역시 타당한 주장이라고 생각한다.

그러나 개인적으로 'Controller는 최대한 간단해야 한다'라고 생각하는 사람이기에 Controller에 너무 많은 연산 과정을 주는 것을 피하기 위해 두 번째 의견을 채택하였다.

첫번째 처럼 Controller가 해당 변환을 수행한다면, A Controller가 A Service, B Service를 호출하여 DTO를 병합하게 될 텐데,,
이는 Controller가 수행하는 역할이 너무 커진다고 생각한다!!
Controller는 View와 Model을 연결하는 역할만 해야 한다고 생각한다!!!