DTO매핑을 해야하는 이유

Springboot + JPA 활용해 과제를 진행하던중 entity를 화면 단에 직접적으로 노출하면 안 된다는 영한 님의 강의 내용이 생각이 났다.

그때는 그냥 강의를 듣고 열심히 코드를 따라 치기만 했지 왜지? 라는 의문점은 다음으로 넘기고 이번에 과제 도중 그런 상황이 생겨서 한 번 정리해보자.

 

우선 entity와 dto를 알아보자.

entity란

• 실제 DB 테이블과 매핑되는 핵심 클래스.
• DB 테이블에 존재하는 칼럼들을 필드로 가지는 객체.

dto란

• DTO(Data Transfer Object) 계층(Layer)간 데이터 교환을 위해 사용되는 객체
• DB에서 데이터를 가져와 Service 및 Controller 등으로 전송할 때 사용하는 객체

 

불필요한 데이터 노출

Entity를 데이터 request or response의 객체로 사용은 하면 안 된다.

setter를 갖게 된다면, controller와 같은 비즈니스 로직과 크게 상관없는 곳에서 자원의 속성이 실수로라도 변경될 수 있다.

엔티티를 UI계층에 노출하는 것은 테이블 설계를 화면에 공개하는 것이기 때문에 보안이 취약할 수 있다.

 

엔티티의 내부 구현을 캡슐화하고 UI계층에 노출시키지 않아야 하는 것은 충분히 데이터 전달 역할로 Dto를 사용해야 할 이유로 볼 수 있다.

 

API 변경 유연성 부족

Entity는 DB와 밀접한 관계이기 때문에 API 응답에 따라 Entity를 수정하는 것은 위험하다.

요청과 응답으로 엔티티를 사용한다면, 요청 화면 속에 필요하지 않은 속성까지 함께 보내지게 되고 이 경우 단순 이름만 보여주면 되는 경우인데 다른 필드까지 함께 보여줌으로써 성능 저하의 문제가 될 수 있고 같은 필드인데 어떨 땐 null이고 어떨 땐 값이 들어가 있으면 유지보수하기 매우 힘들어진다.

 

순환참조 예방

JPA Entity로 개발을 할 때 양방향 참조를 사용했다면 순환참조를 조심해야 한다.

양방향 참조된 Entity를 controller에서 응답으로 보내면 Entity가 참조하고 있는 객체는 지연로딩이 되며 로딩된 객체는 자신이 참조하고 있는 객체를 호출한다.

이렇게 서로 참조하는 객체를 계속 호출하면서 결국 무한 루프에 빠지게 되는 문제를 낳게 된다.

순환참조의 원인은 양방향 매핑 자체에 있을 수 있다. 하지만 양방향 참조를 해야 한다면 순환참조가 일어나지 않도록 응답으로 Dto로 두는 것이 더 안전하다.