DTO vs VO
오늘은 멋사에서 진행중인 스터디에 발표한 내용들을 블로그에 정리해보려고 합니다.
우아한Tech 채널의 DTO vs VO 영상들을 참고하여 작성하였습니다.
DTO와 VO의 혼용 원인이 무엇일까?
구글에 DTO와 VO에 대해 검색해보시면 둘의 차이점에 대해 설명하는 글이 굉장히 많습니다.
그 이유는 무엇일까요?
관련된 자료를 검색해봤는데 요 책이 원인일 가능성이 높다고 합니다.
위 책의 초판에서는 데이터 전달용 객체를 VO(Value Object)로 정의했지만,
2판 부터는 이를 TO(Transfer Object)로 정의를 했습니다.
현재는 데이터 전달용 객체의 정의를 DTO( Data Transfer Object) 라고 부르고있습니다.
그러면 VO랑 DTO는 정확히 무엇을 뜻할까요??
먼저, DTO에 대해 설명하겠습니다.
DTO( Data Transfer Object)
- DTO는 계층( Layer) 간 데이터 전달을 위해 사용하는 객체 입니다.
- 그러면 데이터 전달용으로 사용하는데, 로직이 필요할까요?
- 당연히 없습니다. 그래서 로직은 getter와 setter만 존재합니다.
- 여기서 setter 때문에 의문점이 생길 수 있습니다.
- "setter로 데이터를 변경할 수도 있는거 아니야?"
- 넵 맞습니다 그래서 보통 DTO는 불변객체( 변경 X )인 상태로 만들어서 전달합니다.
- 정말 Data Transfer Object을 뜻하는 그대로 "데이터 전송"이 목적인 로직을 갖고 있지 않는 순수한 데이터 객체라고 생각해주시면 됩니다.
VO( Value Obejct )
- VO는 값 그 자체를 표현하는 객체입니다.
- 이 말이 무슨 말이냐면, 서로 다른 이름을 가졌다고 하더라도 VO의 인스턴스가 모든 속성 값이 같다면 같은 객체라고 판단하는 것입니다.
- 이를 위해서 equals()와 hashCode()를 반드시 오버라이딩을 하셔야 합니다.
- 객체의 불변성을 보장합니다.
- 그래서 DTO를 불변객체로 만드는 것처럼 모든 속성은 private으로 하고, 생성자를 통해 초기화를 해줍니다.
- DTO와 달리 "로직"을 포함할 수 있습니다.
DTO와 VO에 대해서 공부를 하면 "Entity"도 포함해서 설명을 보통 하기 때문에 추가로 설명하겠습니다.
Entity란?
- 실제 DB의 테이블과 매핑되는 클래스 입니다.
- ID로 구분합니다.
- VO처럼 로직을 포함할 수 있습니다.
위에서 DTO vs VO에 대해서 설명한것처럼 Entity는 DTO와 비교를 하는데요, 그러면 대체 무엇 때문에 그런지 알아보겠습니다.
"데이터를 전달할 때 Entity로 DTO의 역할까지 할 수 있지 않을까?"
즉, 위와 같은 생각에 의해서 Entity 클래스를 DTO의 역할인 데이터 전달까지 같이 사용하는 거죠.
물론 가능합니다. 근데 그렇게 사용하면 안됩니다.
그 이유는 다음과 같습니다.
- View에서 표현하는 속성 값들이 클라이언트의 요청에 따라 계속해서 달라질 수 있습니다.
- 수많은 서비스나 비즈니스가 Entity 클래스를 기준으로 동작하기 때문에 변경 시 관련된 클래스가 모두 영향을 받습니다.
그래서 View의 변경에 따라 다른 클래스들에게 영향을 끼치지 않고 자유롭게 변할 수 있는 DTO를 사용하는게 좋고,
DB 모델을 나태는 Entity의 순수성을 유지시키기 위해 Controller에서 쓸 DTO와 Entity 클래스는 분리해서 사용하는게 좋다고 합니다.
이상 포스팅을 마치겠습니다!
참고자료 :
https://www.youtube.com/watch?v=z5fUkck_RZM
https://www.youtube.com/watch?v=J_Dr6R0Ov8E