Entity와 DTO의 연관관계

이번 프로젝트에서는 DB와의 연동이 없었기에 데이터를 DTO를 통해 관리했다. 프로젝트를 하기 전에는 “왜 Entity가 아닌 DTO를 사용하여 데이터를 관리할까?”라는 의문이 있었다. 이를 해결하기 위해 둘의 개념 정리부터 시작했다.

Entity

DTO (Data Transfer Object)

데이터를 이동하기 위한 객체
- Client가 Controller에 요청을 보냄 : RequestDto
- Controller가 Client에게 응답을 보냄 : ResponseDto

❓

그렇다면, 왜 Entity 대신 DTO를 사용할까?

View Layer와 DB Layer역할을 분리
= 객체를 표현하는 계층 ↔ 객체를 저장하는 객체
└ Entity를 UI계층에 노출하는 것은 테이블 설계를 화면에 공개하는 것으로, 보안상 바람직하지 않다.

클라이언트와 통신하는 DTO 클래스는 자주 변경됨
Request, ResponseDTO는 요구사항에 의해 자주 변경되므로 Entity와 분리하여 관리해야함

도메인 모델링을 지키기 위함
- DTO에 표현을 위한 로직을 추가해서 사용해야 Entity의 도메인 모델링을 지킬 수 있음
  - validation 코드와 모델링 코드를 분리할 수 있음
    Entity 클래스에는 상대적으로 복잡한 모델링을 위한 코드(Annotaion)이 추가되있다. 이곳에 @NotNull, @NotEmpty, @NotBlank와 같은 validation을 위한 코드(Annotation)이 추가되면 Entity가 너무 복잡해진다.
    ⇒ validation은 DTO에, 모델링은 Entity에서 분리하여 진행한다.

Uploaded by N2T

for IF