[DB] Entity와 DTO (그리고 VO)

 

 

Entity

실제 DataBase의 테이블과 1:1로 매핑되는 클래스

DB의 테이블 내에 존재하는 컬럼만을 속성(필드)으로 가져야 한다.

Entity 클래스는 상속을 받거나 구현체여서는 안 되며, 테이블 내에 존재하지 않는 컬럼을 가져서도 안 된다.

 

Entity Setter 금지 및 생성자, 접근 제어

Entity를 작성할 때 setter를 무분별하게 사용하면 객체의 값을 변경할 수 있어 객체의 일관성을 보장할 수 없다.

일관성을 유지할 수 있어야 유지 보수성이 올라가기 때문에 Setter를 사용하기 보다는 객체의 생성자에 값을 넣어줌으로써 setter 사용을 줄이는 것을 지향한다.

 

 

 

DTO (Data Transfer Object)

계층간 데이터 교환을 위한 객체. (DB의 데이터를 Service나  Controller  등으로 보낼 때 사용하는 객체)

로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메소드만을 갖는다.

또한, Controller Layer에서 Response DTO 형태로 Client에 전달한다.

 

 

 

VO (Value Object)

값 객체. 중요한 속성은 read only 속성.

핵심 역할은 equals()와 hashCode()를 오버라이딩 하는 것이다.

VO 내부에 선언된 속성(필드)의 모든 값들이 VO객체마다 값이 같아야, 똑같은 객체라고 판별한다.

Getter/Setter를 가질 수 있으며, 테이블 내에 있는 속성 외에 추가적인 속성을 가질 수 있다.

 

 

 

---

 

 

 

Entity와 DTO  분리 이유

DB Layer와 View Layer 사이의 역할을 분리하기 위해서!

• Entity: 실제 테이블과 매핑되어 만일 변경되게 되면 여러 다른 클래스에 영향을 끼침
• DTO 클래스: View와 통신하며 자주 변경됨

결국, DTO는 Domain Model 객체를 그대로 두고 복사하여 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용해야 한다.

 

 

DTO와 VO의 차이점

둘의 개념은 같지만 VO는 read only 속성을 갖는다.

• VO: 특정한 비즈니스 값을 담는 객체
• DTO: Layet간의 통신 용도로 오고가는 객체

 

 

 

 

참고 링크

• velog.io/@gillog/Entity-DTO-VO-바로-알기

 

 

 

 

---