DTO vs VO vs Entity

여는 글

DTO, VO, Entity는 데이터를 담는 공간으로써, 의문을 가져왔습니다.

이젠 그 의문점을 해결해야 한다는 확신에 이 글로 정리해보려 합니다.

DTO (Data Transfer Object, 데이터 전송 객체)

레이어 간에 데이터를 전달하는 객체 입니다.

여기서 레이어는 User - Controller - Service - DAO(Repository) 에서 각 단계를 말하며, Setter 와 Getter 를 가집니다. 하지만 별도의 비즈니스 로직을 가지지는 않습니다.

결론적으로, 비슷한 특성을 가진 값을 하나의 객체로 묶어 레이어간 전달에 유용하도록 만든 자료 구조라고 정리할 수 있겠습니다.

.

VO (Value Object, 값 객체)

DTO와 동일하게 레이어와 레이어 간에 데이터를 전달하는 객체란 점에서 동일하지만, immutable(불변성)을 가집니다. 그래서 DB에서 읽은 값을 VO에 담을 경우, 이 VO의 값이 DB 데이터 원본으로써 신뢰할 수 있으며, DTO와 달리 비즈니스 로직을 가질 수가 있습니다.

.

또한 Object의 equals, hashcode를 오버라이드 함으로써 여러 VO가 있을 때 상호 동일한지 다른지 여부를 확인할 수 있게 해야 합니다.

.

예를 들어, 특정 고객의 한 달간 구매 제품 목록을 VO에 담을 경우 이 제품 목록이 변경되지 않은 값이라고 신뢰할 수 있으며, 구매 총액을 계산하는 등 유용한 비즈니스 로직을 추가 및 사용함으로써 유용하게 활용할 수 있습니다. 그리고, 완전히 구매한 제품 목록이 동일한 고객이 둘 이상 있을 경우 equals 및 hashcode를 사용해 구분 혹은 동일한지 확인할 수 있습니다.

.

Entity

실제 DB의 테이블과 매핑되는 클래스 입니다. Id(PK)를 통해 구분되고, 비즈니스 로직을 가질 수 있습니다.

각 테이블 컬럼이 모두 선언되어 있어서 DTO를 대신해서 쓸 수 있지 않을까 고민하는 경우가 많은데, View에서 요청하는 값은 언제나 변경되는 값이고, 그때마다 Entity를 변경하면 영속성 모델을 구현한 Entity가 순수성을 잃어버릴 수 있어 권장하지 않는다.

전체 Layer 중 값이 바뀔 수 있는 User - Controller- Service 까지는 DTO를 사용하고, 그 이후 Repository에서 ModelMapper 등의 유틸 라이브러리를 사용해 값을 Entity로 옮겨 활용하는 식으로 구현하는 것을 권장한다.

영속성 모델
데이터를 생성한 프로그램이 종료되더라도 사라지지 않는 데이터의 특성을 말한다.
영속성을 갖지 않는 데이터는 단지 메모리에서만 존재하기 때문에 프로그램을 종료하면 모두 잃어버리게 된다.

.

지금까지 DTO, VO, Entity의 차이점을 정리해보았다. 그 다음으로 고민해야할 점은 이 세 유형의 클래스를 패키지에 담을 때 패키지 구성을 어떻게 할 지에 대한 것이다. 꾸준히 토이프로젝트하며 고민해볼 계획이다.