DAO (Data Access Object), DTO(Data Transfer Object), VO(Value Object), Entity
Computer Science
1. DAO (Data Access Object)
-
실제로 DB에 접근하는 객체이다.
- Persistence Layer(DB에 data를 CRUD하는 계층)이다.
-
Service와 DB를 연결하는 고리의 역할을 한다.
-
DB의 data에 접근하기 위한 객체이다. DB에 접근하기 위한 로직을 분리하기 위해 사용한다.
- 이렇게 따로 분리해놓는 이유는 HTTP Request를 Web Application이 받게 되면 Thread를 생성하게 되는데 비즈니스 로직이 DB로부터 데이터를 얻어오기 위해 매번 Driver를 로드하고 Connection 객체를 생성하게 되면 엄청 많은 커넥션이 일어나므로 DAO를 하나 만들어 DB 전용 객체로만 쓰는 것이다. 이러면 부담이 줄어들게 된다.
-
직접 DB에 접근하여 data를 삽입, 삭제, 조회 등 조작할 수 있는 기능을 수행한다.
-
MVC 패턴의 Model에서 이와 같은 일을 수행한다.
DAO에서는 CRUD 작업만 이루어지고 이를 받아 작업을 하는 클래스는 서비스 클래스라고 부른다.
2. DTO(Data Transfer Object)
-
DTO는 계층 간(Controller, View, Business Layer) 데이터 교환을 위한 자바 빈즈(Java Beans)를 의미한다.
-
DTO는 로직을 가지지 않는 데이터 객체이고 getter/setter 메소드만 가진 클래스를 의미한다.
-
계층간 데이터 교환을 위한 객체(Java Beans)이다.
-
DB에서 데이터를 얻어 Service나 Controller 등으터 보낼 때 사용하는 객체를 말한다.
- 즉, DB의 데이터가 Presentation Logic Tier로 넘어오게 될 때는 DTO의 모습으로 바껴서 오고가는 것이다.
-
로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.
- 하지만 DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. (대신 생성자에서 값을 할당한다.)
-
Request와 Response용 DTO는 View를 위한 클래스
자주 변경이 필요한 클래스 -
Presentation Model
-
Controller Layer에서 Response DTO 형태로 Client에 전달한다.
3. VO(Value Object)
-
VO는 값 오브젝트로써 값을 위해 쓰인다.
-
Read-Only 특징(사용하는 도중에 변경 불가능하며 오직 읽기만 가능)을 가진다.
-
DTO와 유사하지만 VO는 getter 기능만 존재한다.
-
여기서 유효성 검사가 많이 이루어진다.
VO는 값들에 대해 Read-Only를 보장해줘야 존재의 신뢰성이 확보되지만 DTO의 경우는 단지 데이터를 담는 그릇의 역할일 뿐 값은 그저 전달되어야 할 대상일 뿐이다.
- 값 자체에 의미가 있는 VO와 전달될 데이터를 보존해야하는 DTO의 특성상 개념이 다르다.
4. Entity
-
실제 DB의 테이블과 매칭될 클래스
- 즉, 테이블과 링크될 클래스임을 나타낸다.
-
Entity 클래스 또는 가장 Core한 클래스라고 부른다.
-
@Entity,@Column,@Id등을 이용 -
최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현한다.
- 단, Domain Logic만 가지고 있어야 하고 Presentation Logic을 가지고 있어서는 안된다.
-
여기서 구현한 method는 주로 Service Layer에서 사용한다.
[Entity 클래스와 DTO 클래스를 분리하는 이유]
- View Layer와 DB Layer의 역할을 철저하게 분리하기 위해서
- 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스(Request / Response 클래스)는 자주 변경되므로 분리해야 한다.
- Domain Model을 아무리 잘 설계했다고 해도 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있다. 이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 된다.
- 또한 Domain Model을 복잡하게 조합한 형태의 Presentation 요구사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어렵다.
- 즉 DTO는 Domain Model을 복사한 형태로, 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용한다.
