왜 DTO를 사용하는가?

DTO(Data Transfer Object)

데이터 전송용 객체 = 엔티티의 사본

 

보통 개발을 하면 직접 엔티티를 사용해서 데이터를 주고 받는 것이 아니라, DTO를 사용하게 된다. 

 

그냥 엔티티 통째로 주고 받으면 되는데, 왜 굳이 DTO를 사용할까?

 

1. 스프링 3계층 (Controller, Service, Repository)간의 전송시 데이터 변환 위험이 있다.

 

2. 클라이언트가 필요 없는 데이터를 포함할 수 있다.

• 시스템 활용 데이터(ex. 생성, 수정시간) 같이 클라이언트에 필요없는 데이터들을 포함한 경우, 네트워크 비용만 올라가고, 보안에 좋지 않다.

3. 클라이언트가 필요한 데이터를 포함하지 않을 수 있다.

• ex) 생년월일을 저장하는데, 나이를 출력해야 하는 경우 (연산이 필요한 데이터)
• ex) 구현 코드상 연관관계가 없는데, 화면에는 같이 뿌려져야 하는 경우가 발생할 수 있다.

4. 단일 책임 원칙 위반

• 클라이언트에서 수정이 발생한 경우 DB까지 영향이 생김
  • (DB에 저장될 정보가 아니라, 서비스에 필요한 정보가 추가로 입력이 필요한 경우
• DB에 수정이 발생한 경우 클라이언트까지 영향이 생김
  • (DB 컬럼명이 변경되면, 클라이언트의 호출명까지 바뀌어야함)

=> 데이터를 옮기는 객체가 하나 일 경우, 여러 계층에서 그 객체에 수정을 가하면 단일 책임 원칙이 깨진다.

 

Entity

데이터 원본, DB로 들어갈(원본이 될) 객체

 

Q. Entity는 setter를 절대 가지면 안되나?

A. 절대라는것은 없다. 업데이트 같이 필요한 경우에는 사용해야함.

 

DTO(사본, 연산) < - >Entity(원본, DB)

 

Q. 위 그림에서 어디까지 DTO를 사용하고, Entity를 사용할까? 또한 Entity, DTO 변환은 어디서 일어날까?

 

V, C, S까지 DTO를 사용한다. 서비스와 레포지토리 사이에서는 DTO를 사용하지 않는다. 

DTO는 계층간의 통신을 의미하기 때문이다.

또한, 데이터 변환은 컨트롤러, 서비스 둘 다 가능하지만, 나는 서비스단에서 처리하는 것이 맞다고 생각한다.