DTO, VO, Entity의 분리

개발 공부를 시작하고 프로젝트를 진행하면서 보통 VO 하나만으로 처리를 많이 해왔었다.

처음에는 MyBatis로 처리했었고 처음 공부하던 당시에는 VO나 DTO나 같은거 아닌가 정도로만 이해했었다.

둘다 데이터베이스 테이블과 동일한 구조로 만들어주고 요청한 데이터를 받거나 데이터를 담아 데이터베이스에 요청을 하는 정도만 생각했고 그렇게만 사용했기 때문이었다.

 

그러나 JPA를 공부하게 되면서 Entity라는 것에 대해 알게되면서 조회 요청에 대해 DTO로 받아야 하는 경우를 보게 되었고, 그때부터 VO, DTO, Entity는 다른건가? 라는 생각을 하게 되었다.

 

그리고 그에 대해 알아보면서 개념을 좀 정리하게 되어 이렇게 기록을 남기게 되었다.

 

일단, 보통 DTO와 VO에 대해 검색해보면 데이터를 전달하는 객체로 크~게 본 개념에서는 동일한 개념이지만 차이가 있었다.

 

 

DTO

DTO(Data Transfer Object)는 Transfer의 의미 그대로 데이터를 전송하는 객체를 말한다.

그래서 데이터를 계층간 전달하는 역할을 한다.

역할을 확실히 분리하기 위해 DTO에서는 데이터를 담고 빼는것. 즉, getter/setter만 처리하고 비즈니스 로직이 포함되어서는 안된다.

첫줄에서의 의미 그대로 '데이터를 담아 다른 계층에 전송'하는 용도 딱 그만큼만 사용하는 것이다.

 

VO

VO(Value Object)는 의미대로 값 자체를 표현하는 객체이다.

값 자체를 표현하기 때문에 불변의 객체로서 역할을 수행해야 하며, 그렇기에 getter는 갖지만 setter는 가질 수 없다.

DTO와는 다르게 데이터를 담기만 하는것이 아니라 값 자체를 표현하기 때문에 비즈니스 로직을 포함할 수 있다.

 

 

Entity

Entity는 데이터베이스와 직접적으로 매핑되는 클래스이다.

직접적으로 매핑되는 클래스이다 보니 테이블과 구조가 동일하다.

Entity는 데이터베이스와 직접적으로 매핑이 되다보니 계층간 전달 목적으로 사용해서는 안된다.

또한, 비즈니스 로직을 포함할 수 있다.

 

 

 

여기저기 알아보며 정리한 내용은 이정도 이다.

그래서 현재 사용하는 방법은 아래처럼 사용하는중.

 

Entity

  매핑되는 테이블과 동일한 구조로 생성. Entity 데이터를 insert, update 해야 하는 경우에는 Entity를 통해 데이터베이스에 요청을 보내 처리하지만 그 외에는 사용하지 않는다.

 

DTO

  데이터 조회시 Entity와 동일한 구조이더라도 왠만하면 DTO를 통해 데이터를 받도록 하고 결과를 DTO로 리턴한다.

 

VO

  막상 이렇게 분리해야 한다고 알고 나니까 아직은 사용할 프로젝트가 없어서 사용해보질 못했다...