1. 들어가며
왜 DTO와 VO를 혼동해서 사용하는가?
이 책이 초반에 getter, setter를 언급하고 데이터 전송을 위해 사용되는 객체는 VO라 언급
그러나 이후 2판부터는 VO가 아니라 DTO라 정정
2. 결론 먼저
DTO = 데이터 전달용
VO = 값 표현용
3. DTO 란?
DTO
= Data Transfer Object
= 데이터를 전달하기 위해 사용하는 객체
= 데이터를 담아서 전달하는 바구니
“계층 간” 데이터를 전달하기 위한 객체
데이터 전달용인 DTO의 특성
- 오직 getter/setter 메서드만을 가짐
- 다른 로직을 가지지 않음
보내는 쪽 -> setter를 사용해 데이터를 DTO에 담아보냄
받는 쪽 -> 전달받은 DTO로부터 데이터를 꺼내는 방식
getter와 setter 외의 로직 메서드는 가지고 있지 않음
데이터를 보내주는 서비스레이어 측에서 setter를 통해 전달하고자 하는 데이터를 담아 반환해줌
(setter 메서드를 삭제하고 생성자를 통해 속성 값들을 초기화하게 만들어 불변객체로 만들면 전달 과정 중에 변조되지 않음을 보장 가능 = 안정적)
데이터를 받는 쪽인 웹 레이어 측에서 getter를 통해 전달받은 데이터를 꺼내서 사용하면 됨
✔️ Entity란?
Entity 클래스는 절대로 요청이나 응답 값을 전달하는 클래스로 사용 X
실제 데이터베이스와 매핑되어 있는 핵심 클래스
(Id로 구분, 로직 포함 가능)
수많은 서비스 클래스나 비즈니스 로직들이 Entity 클래스를 기준으로 동작
Entity 클래스를 기준으로 테이블이 생성되고 스키마 변경
만약, Entity 클래스를 요청이나 응답 값을 전달하는 클래스로 사용한다면 뷰가 변경될 때마다 Entity 클래스를 그에 맞춰서 매번 같이 변경해야 함
Entity 클래스를 변경하면 관련되어 얽혀있는 무수히 많은 클래스들에 영향 미침
-> 요청이나 응답값을 전달하는 클래스로는 반드시 뷰의 변경에 따라 다른 클래스들에게 영향을 끼치지 않고 자유롭게 변경할 수 있는 DTO를 사용해야 함
응답값으로 여러 테이블을 조인한 결과값을 줘야 할 경우가 빈번함
-> Entity 클래스만으로는 결과값을 전달하기 어려운 경우가 많음
-> Entity 클래스와 뷰의 결과값을 전달해주는 DTO는 분리해서 사용해야 함
(스키마 : 데이터베이스의 구조와 제약조건에 대한 명세를 기술한 것
View : 비즈니스 요구사항에서 자주 변경되는 부분 )
✔️Entity를 DTO 대신 사용할 수 있을까?
사용할 수는 있지만,,,
View에서 표현하는 속성 값들이 요청에 따라 계속 달라질 수 있는데, 그때마다 Entity의 속성값들을 변경하면 영속성 모델을 표현한 Entity의 순수성이 모호해지기 때문에 Controller에서 쓸 DTO와 Entity 클래스를 분리하는 것이 좋음
4. VO 란?
VO
= Value Object
= 값 그 자체를 표현하는 객체
(값으로만 비교되는 객체 / 불변객체)
서로 다른 이름을 가진 VO의 인스턴스가 모든 속성값이 같다면 같은 객체
VO의 특성
- 다른 로직 포함 가능
- 생성자를 통해서만 값 초기화
5. DTO vs VO ( vs Entity)
DTO
용도 : 레이어 간 데이터 전달
동등 결정 : 속성값이 모두 같다고 해서 같은 객체가 아님
가변/불변 : setter 존재시 가변, setter 비존재시 불변
로직 : getter/setter 외의 로직을 갖지 않음
VO
용도 : 값 자체 표현
동등 결정 : 속성값이 모두 같으면 같은 객체
가변/불변 : 불변
로직 : getter/setter 외의 로직을 가질 수 있음
Entity
용도 : DB 테이블과 매핑되는 클래스
가변/불변 : 가변
로직 : 로직 포함 가능
참조 링크
라흐의 DTO vs VO
인비의 DTO vs VO
