DTO, Model, Entity

DTO (Data Transfer Object)

• 클라이언트의 데이터를 받는 역할, 클라이언트에서 사용하는 것으로 노출되도 상관 없는 것.
• 계층간에 데이터 교환을 위한 객체임.
  • DB에서 데이터를 얻어 Service나 Controller 등으러 보낼 때 사용하는 객체
  • 로직을 갖고있지 않는 순수한 데이터이며, getter/setter 메서드만을 갖음.
• Request와 Response용 DTO는 View를 위한 클래스
  • 자주 변경이 필요한 클래스
  • Presentation Model
  • toEntity() 메서드를 통해 DTO에서 필요한 부분을 이용하여 Entity로 만듬
  • 또한 Controller Layer에서 Response DTO 형태로 Client에 전달함.
• Domain 대신 DTO를 사용하면, 도메인 모델을 캡슐화 하여 보호할 수 있다라는 장점이 있음.
• python 에선 주로 input이 알맞게 들어왔는지 검증하는 역할을 함.

Model

비즈니스 데이터를 담는 역할

비지니스 데이터 = DB 안에 있는 데이터

즉, 데이터를 “담는” 역할이니, model은 db 구조와 매핑되어야함.

Entity

DB의 테이블과 스키마를 표현하는 역할, DB 컬럼과 연결되기 때문에 필드명 노출되면 안됨

• 실제 DB의 테이블과 매칭될 클래스
  • 즉, 테이블과 링크될 클래스
  • Entity 클래스 또는 가장 Core한 클래스라고 부름
  • @Entity, @Column, @id 등을 이용
• 최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현함.
  • 단, Domain Logic만 가지고 있어야 하고, Presentation Logic을 가지고 있어서는 안됨.
  • 여기서 구현한 method는 주로 Service Layer에서 사용함.
• 레포함수 안에 select 하는 경우에, 서비스 단에 데이터를 넘기는 과정에서 데이터가 서비스 단에 알맞게 넘겨줄 수 있도록 검증해주는 역할.

DTO와 Entity를 분리하는 이유 ?

• View Layer와 DB Layer의 역할을 철저하게 분리하기 위하여
• 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면, View와 통신하는 DTO 클래스는 자주 변경되므로 분리해야함.
• Domain Model을 아무리 잘 설계했다고 해도, 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있음. 이러한 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 됨.
• 또한 Domain Model을 복잡하게 조잡한 형태의 Presentation 요구사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어려움.
• 즉 DTO는 Domain Model을 복사한 형태로, 다양한 Presentation logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용함.

전체적인 구조는 아래와 같음.

refer:
https://velog.io/@pjy05200/DTO%EC%99%80-Entity-Class%EC%9D%98-%EC%B0%A8%EC%9D%B4