DTO , VO , Entity의 간단한 정리 및 비교

비교에 앞서 간단한 개념 설명

• DTO : 순수하게 데이터 전달만을 위한 개체 
  •  getter/setter 메소드 말고 다른 로직은 없다. 
  • 가변성이 있지만 setter 메소드를 제거하고  대신 생성자로 필드에 데이터를 넣으면 불변성을 갖는다. ( 개인적으로 setter 메소드를 제거한 DTO는 반쪽짜리 VO라고 해도 무방한 것 같다. 딱 VO에서 euals(),hashCode() 만 오버라이드만 안한 상태? )
  • 보통 변화에 민감하지 않는 , 값을 비교할 필요 없는 데이터를 이동시킬 때 사용한다.
• VO : 값 그 자체를 나타내는 객체
  • 데이터의 변화가 없는 불변성을 갖는다.( setter 메소드 사용하지 않는다. )
  • 서로 다른 VO여도 갖고 있는 데이터가 같으면 같은 객체라고 정의한다.(그림2 참고) , 이를 위해 equals() , hashCode() 메소드를 오버라이드 해줘야 한다.
  • 변화에 민감한 , 비교 로직이 사용될 데이터를 이동시킬 때 사용한다.
• Entity : DB의 table과 1대1 맵핑되는 객체 , DB와 직접적으로 소통하는 객체
  • 이거 기준으로 DB의 table이 생성되고 schema가 변경된다.

 

이 셋의 비교는 2번으로 나눠서 하는게 이해하기 편할 것 같다. 우선 아래와 같이 비교해보자

 [ DTO(대표) , VO ]   vs  [ Entity ] 

• DTO 와 Entity둘을 분리해 사용하는 가장 큰 이유는 영향력이다. 둘다  데이터를 담고 있다는 점에서는 유사하다, 하지만 수많은 서비스 , 비지니스 로직들이 Entity(+Entity와 연결된 DB)를 기준으로 동작한다. 그런 Entity가 자주 이동되고 , 변경되다가 에러가 날 경우 그 영향은 DTO와는 비교할 수 없다. 또한 DB와 다른 계층들을 분리하면 유지보수성과 안정성을 확보하기에도 좋기 때문에 DTO 와 Entity의 역할을 분리해서 사용한다.
• 아래 <그림1>은 내가 이해한 대략적인 DTO,Entity 사용처이다.
• 아래 <그림1>은 Repository에서 ( DTO를 Entity로 ,Entity를 DTO로 ) 변환시켰는데 사실 명확하게 어디에서 변환시켜야 한다는 정의는 없다. Servie에서 변환할 수도 있고 Controller에서 변환할 수도 있다. 또 그 방법들 틀린게 아니라 각각의 장단점이 존재한다. 

<그림1>

 

---

 

 [ DTO ]  vs  [ VO ]

• 글 처음에 나온 개념을 읽으면 알겠지만 둘의 큰 차이점 2가지이다.
  
  1. DTO는 가변성(상황에 따라 불변성) , VO는 불변성
  2. VO는 담고있는 데이터만 같다면 서로 다른 두 객체도 같은 객체라고 본다. 아래 <그림2>에서 노랭이와 초록이는 서로 다른 새지만 물고있는 데이터만 같다면 둘은 같다고 정의하는게 VO다.
  3. 그래서 데이터가 같은지 비교하는 작업이 많은 경우 VO 적절할 수 있다.

<그림2>

 

 

 

 

 

( 참고. 초심자가 개념을 잡을려고 혼자 끄적인 글입니다. 틀리거나 다른 부분도 많을 테니 지적해주심 부지런히 수정하겠습니다 👍 )