DTO와 Entity를 분리하는 이유

프로젝트를 진행하면서 request, response DTO로 변환한다는 얘기를 듣고 코드를 작성하는데 그 이유를 도무지 알 수 없어서 코드 작성에 어려움이 있었다. 그래서 찾아보았다.

Entity를 보호할 수 있다

• entity가 노출되면 자원의 속성이 변경될 가능성이 있다.
• UI계층에 노출하면 테이블 설계를 공개하는 것이기에 보안상 바람직하지 못한 구조가 된다.
• DTO는 setter를 허용하지만 entity에서 setter를 무분별하게 사용하면 안된다.

화면에 필요한 데이터 선별 가능

• 화면 구성에 필요한 데이터들만으로 작성이 가능하다.

Entity를 view에 그대로 넘기면 view의 요구사항이 변할때 Entity를 수정해줘야하는 번거러움 발생한다.

순환참조 예방

• jpa에서 양방향 참조된 엔티티를 controller에서 반환하면 순환참조가 발생하여 무한 루프에 빠져 스택오버 플로우 발생
• DTO를 사용하는 것이 안전하고 또한 많이 추천한다.

validation 코드와 모델링 코드를 분리할 수 있다.

• Entity에는 @Column, @JoinColumn, @ManyToOne 등의 모델링 코드가 추가되는데 여기에 @NotNull, @NotEmpty 등 validation 코드가 들어가면 복잡해지고 가독성 저하된다.
• validation 코드를 DTO에서 정의하면 Entity 클래스를 좀 더 모델링과, 비즈니스 로직에만 집중하도록 만들 수 있다.

DTO <-> Entity 변환 위치

• service에서 DTO -> entity 수행하면 entity만 사용 가능
• controller에서 entity -> DTO 수행

DTO <-> Entity 변환 메서드

• DTO에서 toDto(), toEntity() 메서드 작성
  -> entity에서 만들면 dto 수정할 때 entity 코드 수정해야해서 entity가 dto에 의존적이게 된다.

[참고 블로그]https://velog.io/@0sunset0/Dto와-Entity를-분리하는-이유-분리하는-방법