📌 DTO와 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를 어디 계층까지 사용하여야 할까

서비스 레이어가 가장 적합하다고 생각한다

Service 레이어의 정의

• 어플리케이션의 경계를 정의하고 비즈니스 로직 등 도메인을 캡슐화하는 역할
• 즉 도메인을 보호
• 도메인을 표현 계층에서 사용할 경우 결합도가 증가하여 도메인 변경이 Controller의 변경을 촉발한다.
• 이는 유지보수의 문제로도 이어질 수 있다.

Controller가 DTO를 생성하면 생기는 문제

• Controller가 DTO를 완벽하게 도메인에서 객체로 구성한 뒤 서비스에게 넘겨주려면 복잡한 경우 Controller가 여러 서비스나 Repository에 의존하게 된다.
• Controller가 여러 도메인 객체들의 정보를 조합해서 DTO를 생성해야하는 경우 결국 Service 로직이 Controller에 포함되게 된다.

참고 자료

• [10분 테코톡] 🎼라흐의 DTO vs VO
• DTO의 사용 범위에 대하여