[Spring] DTO와 Entity 분리 필요성

새로운 프로젝트를 시작하게 되면서, DTO와 Entity간의 매핑방식에 대해 고민해보는 시간이 주어졌다.

그리하여 조사과정과 결론도출까지의 과정을 기록해보려고 한다.

이후에 실제 프로젝트가 어떤 방식을 채택했는지에 대해 남길만한 내용이 있다면 이어 블로그를 남기도록 하겠다!

---

Entity 과 DTO 분리해야할까?

경력직으로 오신 선배분은 DTO없이 개발했던 경우도 있었다고 말씀하시기도 해서 분리의 필요성에 대해 먼저 생각해보았다.

DTO를 Entity와 분리하여 사용할 때 DTO 내에 Entity로 매핑하는 코드가 길어져 간결하지 않게 느낄 수 있을 것 같다.

 

출처 : https://velog.io/@langoustine/Entity-말고-DTO를-쓰라고

spring에서 JPA를 이용하게 되면 Entity는 단순히 데이터를 담는 객체가 아니라 DB Layer(실제 데이터베이스)와 데이터를 주고받을 때 사용하는 것이기에

View Layer(요청 및 응답 클래스)와 데이터를 주고 받을 때는 DTO를 사용해야 하고 Entity를 데이터 요청/응답 객체로의 사용은 지양해야 한다.

Entity는 데이터베이스 영속성(persistent)의 목적으로 사용되는 객체이기에 요청 및 응답값을 전달하는 클래스로의 사용은 좋지 않다.

 

[Entity와 분리하여 DTO를 사용할 때의 이점]

1. Entity를 캡슐화할 수 있다.

 

Entity는 DB 테이블과 매핑되는 클래스로 데이터 전달 역할을 하도록 getter와 setter를 가지게 된다면 controller와 같은 곳에서 변경될 가능성이 있다.

또한 View Layer를 통해 통신하게 된다면 테이블 설계를 그대로 공개하는 것이기에 보안적으로 좋지 못하다고 볼 수 있다. 그렇기에 별도로 요청 및 응답 역할을 담당하는 DTO 객체를 만들어 사용해야 한다.

 

2. View Layer와 DB Layer의 역할을 분리할 수 있다.

 

Entity를 요청 및 응답 객체로 사용한다면 사용자의 이름만 보여주면 되는 상황에서 Entity를 통해 사용자 이름뿐 아니라, 다른 정보까지 포함하여 보여주게 된다. 그러면 모든 요청과 응답에서 Entity의 모든 내부 정보를 함께 전송하기에 속도도 느려지고 보안적으로도 바람직하지 못하다.

 

 

🧐 결론 : Entity와 DTO 분리는 위 내용에 따라 원칙상 불가피함.

 

 

++

하지만 이전 프로젝트의 경험 상 API별로 request용 response용 등의 DTO 너무 많아져 복잡해질 수 있고,

Entity들의 데이터를 가공하여 DTO에 Set Method 혹은 builder로 매핑하는 코드가 길어져 간결하지 못한 점이 걸림.

이에 대한 개선방법을 찾아본 결과,

 

1) DTO 수 줄이는 방법

  출처 :  https://velog.io/@p4rksh/Spring-Boot에서-깔끔하게-DTO-관리하기
   하나의 도메인에 관련된 DTO를 하나로 만들어 준 후 Inner Class로 DTO들을 구현하여 Over-Fetching 줄이기

   아쉽지만 이미 DTO구성방식은 내려왔기 때문에 이번 프로젝트에 적용하긴 어려워 보인다.
   
2) Entity 매핑을 간결하게 하는 방법

  빌더를 사용하지 않고 맵핑 프레임워크 활용
  ( DTO와 Entity 변환 방식 : https://hellotaja.tistory.com/9)