DTO, VO, Entity

DTO (Data Transfer Object) 

VO (Value Object)

Entity

 

과거에는 DTO와 VO를 혼용하여 사용되는 경우가 많았다.

하지만 3가지는 모두 의미가 다르며 활용법도 다르다.

각각의 의미와 특징을 살펴보자.

 

DTO ( Data Transfer Object )

의미

Data Transfer Object 를 직역하면 데이터 전달 객체 이다. 말 그대로 프로세스간에 데이터를 전달 하는 객체이다.

프로세스란 사용자(Client) 또는 화면단 과 어플리케이션 사이에서 이루어 지는 동작들 이다.

• Client 또는 presentation Layer →(DTO)→ Controller →(DTO)→  Service →(DTO)→ Dao
• Dao →(Entity)→ Service →(DTO)→ Controller →(DTO)→ Client 또는 presentation Layer빨간색 : 이 구간에서 DTO 사용시 사용 비용이 굉장이 커진다. 이유는 아래 특징에서 설명된다.

특징

1. getter / setter 이루어져 있으며 비즈니스 로직을 포함하지 않는다.

 

많은 곳에서 getter/setter 외에 모든 로직을 가져서는 안된다고 말한다.

하지만 마이크로소프트 문서 에서도 말했듯이 비지니스 로직을 포함하지 않는 것 이라고 언급 되었으며 getter/setter만 가져야 된다고 한것은 아니다.

데이터 전달용 이라는 컨셉을 잊지 않고 POJO 형태를 유지하면서 다른 로직과 종속되지 않는 환경을 만든다면 사용 목적에 따라 충분히 다른 로직을 포함시켜도 나쁘지 않을 것 같다. 

 

2. 마틴 파울러가 말했듯이 DTO는 Presentation Model에 적합하다.

마틴파울러의 이글을 읽어보면 DTO는 단점이 많다.

coarse grained형태의 API 경우 수 많은 데이터를 DTO에 맵핑시켜줘야 한다.

Service layer에서의 DTO는 DB에 맞춰 DTO를 모두 만드는 시간과 객체 관계 맵핑에 대해 고민하는 비용이 매우 크다.

 

하지만 DB데이터와 Client 또는 사용자에게 받고 보내는 데이터 (Presentation Model) 는 다르고 서로 부조합 하기 때문에 DTO로 구분하여 사용하면 매우 적합하다.

 

[읽으면 도움이되는 문서]

DTO가 REST API 에서 사용되어야 하는 이유 https://stackoverflow.com/a/36175349

VO ( Value Object )

의미

Value Object 값 객체

값을 가지고 그 값 자체를 표현하는 객체를 말한다.

어떠한 특정한 정체성 또는 id를 가진 객체가 아니고 순수 값을 포함한 객체라는 것이다.

순수 값이기 때문에 불변성을 유지해야한다.

순수 값을 나타내는 것들은 돈, 날짜, 숫자 등이 있다.

 

예를 들어 국영수 시험점수를 나타내는 VO를 만든다고 가정하자.

class 시험점수VO {

시험점수VO(국어, 영어, 수학){

    ...

 }

 private int 국어, 영어, 수학

  ... getter, setter

}

 

List<시험점수VO> 시험점수_리스트;

 

시험점수 리스트에서 점수가 모두 100점인 데이터를 찾는다면

for( 시험점수VO : 시험점수_리스트 ){

  aasert(시험점수VO.equals(new 시험점수VO(100, 100, 100));

}

 

이렇게 equals를 이용하여 비교될것이다.

하지만 객체이기 때문에 객체안의 값이 같아도 결과는 false가 나올 것이다.

이때문에 equals와 hashcode를 override 하여 구현해 줘야한다.

 

특징

Entity 

Entity는 흔히 데이터베이스에서 사용되는 단어이다.

 

인간이 생각하는 개념 또는 정보의 세계에서는 의미있는 정보의 단위로서, 파일 처리시스템에서는 한건의 자료를 구성하는 레코드가 하나의 엔티티에 해당한다. - http://naver.me/5pN3FE9U

 

이로서 Entity는 어플리케이션 단에서도 DB를 나타내는 개체로 표현되어 DB 컬럼과 완전 매칭되어 구성된다.

 

 

다양한 정보들을 찾아보면 어느곳에는 로직을 구현하면 안되고 또 어느 곳에서는 로직을 구현할 수 있다라고 말한다.

모두 일리가 있는 말이지만 항상 그랬듯이 개발에는 정답이 없으며 사람의 판단으로 만들어 나아가는 것이다.

내가 사용하려고 하는것에 대한 의미를 충분이 알고 내 환경에 맞게 최적의 방법을 선택하여 사용하면 되는것 같다.