Domain(Entity) / DTO / DAO

전체구조

 

Entity

실제 DB 테이블에 대응하는 하나의 클래스로, DB의 테이블 내에 존재하는 컬럼만을 필드로 가져야한다. 

 

Entity클래스는 도메인이라고 하며 가장 DB와 가까운 클래스이다.

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

최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method를 구현해야한다.

 

DTO(Data Transfer Object)

계층간 데이터 교환을 위한 객체로 DB에서 얻은 데이터를 Controller나 Service 로직에서 사용하기 위한 객체이다.

로직을 가지고 있지않은 수순한 데이터 객체로 getter/setter 메서드만 갖는다. (DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. 대신 생성자에서 값을 할당한다.)

 

 

DAO (Data Access Object)

DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트로 실제로 DB에 접근하는 객체다.

DAO는 프로젝트의 서비스 모델과 실제 데이터베이스를 연결하는 역할을 하며, JPA에서는 DB에 데이터를 CRUD 하는 Repository 객체들이 DAO라고 볼 수 있다.

 

Entity와 DTO를 분리해야하는 이유

 

1. Entity와 DTO를 분리해서 관리해야 하는 근본적인 이유는 관심사가 서로 다르기 때문이다.

DTO는 데이터를 담고, 다른 계층(Layer) 또는 다른 컴포넌트들로 데이터를 넘겨주기 위한 자료구조(Data Structure)이다.
반면 엔티티 또는 도메인 객체는 다른 계층이나 컴포넌트들 사이에서 전달을 위해 사용되는 객체가 아니며, 핵심 비즈니스 로직을 담은 비즈니스 도메인 영역의 일부이다.

엔티티와 DTO는 엄연히 서로 다른 관심사를 가지고 있기에 분리하는 것이 옳다.

 

2. 데이터 변경 방지

테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스(Request / Response 클래스)는 자주 변경되므로 분리해야 한다.(Entity 클래스 보호)

각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있다. 이런 경우 Domain Model 내에 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 된다.

 

 

참고

https://mangkyu.tistory.com/192

https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html