Dto, Vo, Entity의 차이점과 쓰임에 대해서

글의 목적

'스룸' 프로젝트에서 Dto, Vo, Entity를 구분하여 사용함으로써 각 객체의 역할을 정의하고자 합니다.

 

DTO란?

Data Transfer Object, 계층간 데이터 전송을 위해 사용되는 객체입니다.

특징

1. Getter, Setter만 가지며, 오직 통신 용도로만 쓰여 로직을 포함하지 않습니다.

스룸에서의 쓰임

controller와 service의 데이터 전송, service와 repository(대부분 entity를 전달하지만 특정 형태의 데이터를 받아오는 경우)사이의 데이터 전송, 각 service간의 데이터 전송에서 쓰입니다.

VO란?

value object, 불변객체로써, 모든 속성값이 같으면 같은 객체입니다.

특징

1. equals(), hashCode()를 재정의하여 모든 속성값이 같을 시 같은 객체인 것을 확인 가능하게 해야 합니다.

2. 로직을 가질 수 있습니다.

3. 객체의 불변성을 보장합니다. (setter x)

스룸에서의 쓰임

스룸에서는 vo에게 책임을 부과하여 로직을 수행하게 합니다.

예를들면 강의 등록 조건 속성을 포함하는 EnrollCondition Vo는 course 와 courseVideo 객체를 생성하는 로직을 수행할 수 있습니다.

또 다른 예로는 Course 객체인데, 이 객체는 일평균 목표 학습시간이 바뀌었거나 영상 순서가 바뀌었을 경우, 영상이 추가가 되었을 경우 각 영상의 주차를 다시 계산하게 됩니다.

 

VO를 DTO 와 구분하여 얻은 이점

기존에는 vo 개념없이 controller, service, repository를 제외한 모든 객체는 dto로 쓰여 데이터 전송만이 가능했습니다.

Vo를 Dto와 구분하면서 생긴 이점은 모든 책임과 로직이 집중되어 있었던 Service 계층에서 각 vo에게 책임을 나누어줄 수 있었다는 것입니다.

책임을 적절히 나눔으로서 비지니스 변경사항에 대해 적은 코드수정으로 대응 할 수 있고, 각 객체간의 메시지 전달을 통해 간결하게 로직을 수행할 수 있었습니다.

Entity란?

실제 db 테이블과 매핑되는 클래스입니다. 이전에는 dto와 혼동되어 entity라는 단어를 사용하지 않았는데, 이는 jpa에서만 쓰이는 단어라고 생각했기 때문입니다.

특징

1. id(pk) 값을 가집니다 (vo와 다른점)

2. 로직을 포함할 수 있습니다.

3. 상태 변경이 가능합니다.

 

아직 궁금한 점

dto는 getter, setter 외에 기능은 허용하지 않는것이 원칙이지만, 제가 생각할 때 vo 또는 도메인으로 매핑하는 메서드는 있는것이 유리할 것 같습니다. 이유는 dto의 필드값이 수정되거나 추가되었을 때, mapper 메서드만을 수정하여 다른 객체는 수정되지 않도록 할 수 있기 때문입니다.

(이걸 로직이라고 생각하지 않으면 되는건지?)

다음은 youtube 에게서 받아온 playlistDto 객체이며, 이를 사용하기 위한 playlist 객체로 매핑하는 메서드가 포함되어 있습니다.

현업에서는 데이터 전송 객체에 정말 getter, setter만을 허용하고 있는지? 어느정도로 확실하게 구분하고 있는지 궁금합니다.

자바와 스프링 강의를 제공하는 Baeldung에서는 다음과 같이 mapper를 생성해야 한다고 말하고 있습니다.

https://www.baeldung.com/java-dto-pattern