1. DTO
Data Transfer Object의 약자. 쿼리 결과값을 리턴받을 때 사용, 프로젝트 때마다 통신시 보내줄 때 사용.
계층간 데이터 교환을 위한 객체.
- 값을 전달할 뿐, Immutability(불변성)의 특성을 가진 것은 아니다. - 수정자가(setter) 있을 수 있다.
- 단, Response Dto는 불변성을 가질 수 있다. => final 키워드 붙일 수 있다는 말!
2. VO
Value Object의 약자. 클래스 맴버변수들의 값 그 자체를 가진다. equals()와 hashcode() 메서드를 오버라이딩 하는 것으로 구성된다.
-
Immutability(불변성)의 특성을 가진다. - 수정자가(setter) 없다.
-
식별자가 없다. 즉, 필드 id가 없다.
-
VO끼리 비교할 경우에 많이 쓴다. - equals()로 오버라이딩(재정의)해서 비교해줘야 한다.
-
DDD(도메인주도설계)에서는 식별자를 가지지 않는 도메인 객체를 VO라고 한다.
VO에 대한 자세한 내용은 이 블로그로 참고하시길. https://velog.io/@livenow/Java-VOValue-Object%EB%9E%80
3. Entity
DB 테이블 그 자체이다.
DB Table과 1:1로 매핑되는 클래스로 어노테이션 @Enttiy로 만들어진 클래스라 보면 된다.
-
Immutability(불변성)의 특성을 가진다. - 수정자가(setter) 없다.
=> 불변성의 특징은 수정을 아예 안한다는 뜻이다. 하지만 Entity는 DB의 테이블과 1:1로 매핑하는 테이블로 POJO한 특징을 가질 수 있는 거지, update, delete 등 변경이 될 수 있는 객체로 사용해야 해서,불변하지는 않다! -
필드에 final 키워드를 쓰지 않는다. -
식별자가 있다. 즉, 필드가 id가 있다.
-
DDD(도메인주도설계)에서는 식별자를 가진 도메인 객체를 Entity라고 한다.
DTO, Entity 클래스들을 분리하는 이유
Entity와 DTO를 분리해서 관리해야 하는 이유는 DB 레이어, 비즈니스 레이어, 프론트 레이어 의 레이어 아키텍쳐 구성에서 분리하고 레이어간 전송하기 위함이다.
DTO 클래스는 클라이언트가 던진 데이터에 따라 받아줘야하는 그릇이기에 그 안에 Data들이 자주 변경될 수 있다. 반면에, Entity는 Domain Model 객체로 Persistence만을 위해서 사용되기에 DB 클래스 칼럼 그 자체로 변경되지 않고 사용해야 한다.
그래서 Entity 클래스에선 setter 같은 변경메서드를 쓰지 않는다.
애초에 변경을 하면 안되기 때문이다. Test시 변경해야 되는 걸 확인하고 싶다면 DTO 클래스 내의 별도의 Method를 만들어서 쓰면 된다. ( ex) DtoToEntity() )
패키지 관리에서도 domain 패키지내에 dto, entity로 분리하는 것이 관례다.
참고
