2021-05-26글
[10분 테코톡] 🎼라흐의 DTO vs VO을 들으며 정리한 글입니다.
DTO
- Data Transfer Object (데이터 전송 객체)
- 계층 간 데이터 교환을 위해 사용하는 객체
- 로직을 갖고 있지 않은 순수한 데이터 객체
- 데이터를 전송하는 바구니
- getter/setter 메서드만을 가짐
VO
- value Object (값 객체)
- 값 그 자체를 표현하는 객체
- 서로 다른 이름을 가진 VO의 인스턴스가 모든 속성 값이 같다면 같은 객체
- equals / hashCode를 오버라이드 필수
- 객체의 불변성을 보장
- 로직을 포함할 수 있음
DTO VS VO
웹 개발에서 사용하는 VO는 사실 DTO이다.
혼동의 원인은..?
이 책에서 getter와 setter가 있고, 데이터 전송을 위해 사용하는 객체는 VO라고 정의해버렸다.
(후에는 변경되었긴했지만)
DTO를 VO처럼 불변 객체로 사용하면 얻을 수 있는 이점?
DTO가 전송하고자 하는 데이터가 전송 과정 중 변조되지 않음을 보장할 수 있음
Entity
- 실제 DB의 테이블과 매핑되는 클래스
- id로 구분
- 로직을 포함할 수 있음
Entity를 DTO대신 사용할 수 있지 않을까?
사용할수는 있지만,
View에서 표현하는 속성값들이 요청에 따라 계속 달라질 수 있는데,
그 때마다 Entity의 속성값을 변경하면 영속성 모델을 표현한 Entity의 순수성이 모호해지기 때문에 Controller에 쓸 DTO와 Entity 클래스는 분리하는 것이 좋다.
정리
| DTO | VO | Entity | |
|---|---|---|---|
| 용도 | 레이어 간의 데이터 전송 | 의미 있는 값을 표현 | DB 테이블과 매핑되는 클래스 |
| 가변 / 불변 | 가변 객체 | 불변 객체 | 가변 객체 |
| 로직 포함 여부 | 로직을 포함할 수 없음 | 로직을 포함할 수 있음` | 로직을 포함할 수 없음 |
추가 - DTO를 어디 계층까지 사용하여야 할까
서비스 레이어가 가장 적합하다고 생각한다
Service 레이어의 정의
- 어플리케이션의 경계를 정의하고 비즈니스 로직 등 도메인을 캡슐화하는 역할
- 즉 도메인을 보호
- 도메인을 표현 계층에서 사용할 경우 결합도가 증가하여 도메인 변경이 Controller의 변경을 촉발한다.
- 이는 유지보수의 문제로도 이어질 수 있다.
Controller가 DTO를 생성하면 생기는 문제
- Controller가 DTO를 완벽하게 도메인에서 객체로 구성한 뒤 서비스에게 넘겨주려면 복잡한 경우 Controller가 여러 서비스나 Repository에 의존하게 된다.
- Controller가 여러 도메인 객체들의 정보를 조합해서 DTO를 생성해야하는 경우 결국 Service 로직이 Controller에 포함되게 된다.
