TIL - DAO, DTO, Entity ?

YulHee Kim·2021년 10월 17일
0
post-thumbnail

✔️ DAO란?

DAO는 Data Access Object다.

  • 실제로 DB에 접근하는 객체다.
    • Persistence Layer(DB에 data를 CRUD하는 계층)이다.
  • Service와 DB를 연결하는 고리의 역할
  • JPA에서는 DB에 데이터를 CRUD 하는 Repository 객체들이 DAO라고 볼 수 있다.
    예시)
public interface QuestionRepository extends CrudRepository<Question, Long> {
}

✔️ DTO란?

DTO는 Data Transfer Obejct다.

  • 계층간 데이터 교환을 위한 객체(Java Beans)이다.

    • DB에서 데이터를 얻어 Service나 Controller 등으로 보낼 때 사용하는 객체를 말한다.
    • DTO는 그저 계층간 데이터 교환이 이루어 질 수 있도록 하는 객체이기 때문에, 특별한 로직을 가지지 않는 순수한 데이터 객체여야 한다.
  • Request와 Response용 DTO는 View를 위한 클래스

    • 자주 변경이 필요한 클래스
    • Presentation Model
    • toEntity() 메서드를 통해서 DTO에서 필요한 부분을 이용하여 Entity로 만든다.
    • 또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.

✔️ Entity Class

  • 실제 DB의 테이블과 매칭될 클래스 (DB의 테이블에 존재하는 Column들을 필드로 가지는 객체)
  • Entity 클래스는 다른 클래스를 상속받거나 인터페이스의 구현체여서는 안된다.
  • 최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현한다.

✔️ Entity 클래스와 DTO 클래스를 분리하는 이유

  • View Layer와 DB Layer의 역할을 철저하게 분리하기 위해서
  • 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스(Request / Response 클래스)는 자주 변경되므로 분리해야 한다.
  • 도메인 설계가 아무리 잘 되었다 해도 Getter만을 이용해서 원하는 데이터를 표시하기 어려운 경우가 발생할 수 있는데, 이 경우에 Entity와 DTO가 분리되어 있지 않다면 Entity 안에 Presentation을 위한 필드나 로직이 추가되게 되어 객체 설계를 망가뜨리게 된다. 때문에 이런 경우에는 분리한 DTO에 Presentation 로직 정도를 추가해서 사용하고, Entity에는 추가하지 않아서 도메인 모델링을 깨뜨리지 않는다.

참고 블로그)

profile
백엔드 개발자

0개의 댓글