[10분 테코톡] DTO vs VO with 인비, 라흐, 지노&비모

우아한Tech 채널의 DTO vs VO 영상들을 보고 저의 방식으로 풀고 첨가해 글을 작성했다.

현재 날짜를 기준으로 같은 주제로 세 개의 영상이 올라와있었는데

거의 동일한 내용이기에 하나의 영상만 보아도 될 것 같다.

그 중 최신의 영상만을 첨부한다.

또한, 발표 영상 후 부가 설명을 직접 포스팅 하셨으니 이 또한 첨부한다. (https://velog.io/@taehee-kim-dev/DTO-vs-VO)

꼭 이 포스팅까지 보기를 추천한다.

 

 

DTO (Data Transfer Object)

- 계층간 데이터를 전달하기 위해 사용하는 객체

- 게터와 세터외에 다른 로직을 필요로 하지 않는다.

=> 순수하게 데이터 전달만을 위한 객체이기 때문이다.

 

VO (Value Object)

- 값 그 자체만을 표현한다.

- 게터, 세터 외의 로직을 포함할 수 있다.

- 값으로만 비교가 되기 때문에, equals()와 hashCode()를 오버라이딩 해주어야 한다.

: java의 여러 자료구조의 객체 동등 비교는 equals() 함수와 hashCode() 함수를 바탕으로 이루어지기 때문이다.

- 값이 쉽게 변할 수 있다면 값을 표현하는 본래 목적에 어긋나게 되기에 불변성을 보장해주어야 한다.

=> setter를 갖지 않는다.

 

Entity Class vs DTO Class

- Entity Class는 실제 스키마와 매핑되는 역할을 하는 클래스이다.

- View와의 통신에 주로 쓰이는 DTO Class는 변경할 일이 잦다.

=> DTO Class를 Entity Class와 구분하지 않고 Entity Classdml 변경이 잦아진다면,

여러 클래스들과 의존성을 갖는 Entity Class의 특성 상 문제가 생기기 쉽다.

 

왜 우리는 이 객체들을 구분해야 사용해야 하는가?

- 왜 이 세 객체를 구분해야하는가? 라고 생각해본다면 나는 객체 지향 개발의 '단일 책임 원칙'을 먼저 들고싶다.

애초에 세 객체의 목적이 다르고,

세 객체를 복합해 사용하게 된다면 객체간의 결합도가 증가하고, 응집도는 떨어지게 된다.

결합도가 증가하고, 응집도가 떨어지는 설계가 왜 좋지 못한 설계인지는 이 글에 따로 서술하지 않겠다.

 

결론: DTO, VO의 목적에 대해 알아보았고, OOP적 관점에서 좋지 못한 설계이기 때문에 이 둘을 분리해 사용하도록 하자.