배경
어쩌면 프로젝트를 진행하면서 설계 단계에서 중요한 부분을 간과했던 점이다.
바로 entity를 그대로 반환하는 방식과 DTO(Data Transfer Object)로 변환한 후 반환하는 방식에 대한 문제인데,
구현을 진행하면서 느낀 점은
- 팀원과 더 정확한 설계를 하지 않았다는 점
- 위의 문제점으로 인해 코드의 일관성이 떨어진다는
이번에 이야기할 문제는 일부 코드에서는 엔티티를 직접 반환하여 API 호출을 하는 반면, 다른 코드에서는 DTO로 변환하여 반환하는 경우가 있으며, 이러한 문제를 해결하기 위해 그리고 문제점을 찾다가 어떤 문제가 있는지, 왜 이러한 방식을 선호하는지에 대해 포스터를 기록하려고 한다.
일기 같이 써질수도 있고, 일부는 구글 상단에 노출된 블로그 글을 그대로 가져온 글이 될 거 같지만, 최대한 이해를 한 바탕으로 이야기를 해보겠다 😶
🔨 엔티티로 반환하는 경우
이러한 방식으로 구현을 했을 때 장점은
빠른 개발
성능
보안 문제
중간에 DTO로 변환하는 로직이 없으니,
코드가 간결해지고, 변환 과정이 없기 때문에구현이 빠르다. 이에 DTO로 변환하는 과정이 없으므로 성능이미세하게 향상이 된다.
단점은
민감한 정보 유출 가능성
유지보수 어려움
일관성 부족
엔티티를 직접 반환하기 때문에 당연히 민감한 정보가 포함된다면 노출이 쉬울 수 있다.
(예를 들어 entity의 테이블 이름이 그대로 노출되기 때문에 보안 문제가 생긴다.)
그리고 구현을 하면서 엔티티의 구조가 변경이 되는 상황이 올텐데,
이 때 구조가 변경되면 API 응답에도 영향이 미쳐유지보수에 어려움을 느낄 수 있다.
또한, 다양한 entity를 반환한다면,일관성이 부족할 수 있다.
🔨 DTO로 반환하는 경우
이러한 방식으로 구현을 했을 때 장점은
보안
유연성
필요한 데이터만 선별 가능
순환 참조 방지
DTO를 사용하면 클라이언트에게 필요한 데이터만 노출할 수 있어
보안성이 높아진다.
DTO 구조를 변경하더라도 엔티티와의 의존성을 줄일 수 있어 API의유연성이 증가한다.
★★★★
entity 클래스의 객체 즉,
도메인 객체는 필요한 정보 이상의 속성을 가지고 있다. 하지만 반대로 클라이언트가 필요한 데이터는 entity의 모든 필드가 아닐 수 있다.
이러한 경우에 dto를 사용하여 필요한 필드만 포함 후 반환할 수 있기에 불필요한 데이터를 보내지 않아도 된다.
★★★★
jpa에서 양방향 참조된 데이터를 즉, entity로 바로 반환을 할 때 Entity가 서로 참조하는 객체를 계속 호출하는 경우가 생길 수 있음 여기서
controller에서 entity를 바로 반환하면, 순환 참조가 발생하는 상황이 나올수도 있는데, 결국 무한 루프에 빠지게 되며 stackover flow가 발생한다.
이에 두 가지 방법이 있는데,
https://velog.io/@jbong/JsonIgnore-Spring
위 포스터처럼@JsonIgonore를 쓰는 방법도 있지만,dto를 사용하는 것이 안전하고 선호하다고 한다.
🔨 어떻게 하나 ?
엔티티로 반환하는 경우라면
보통 스프링 구조에서 엔티티를 생성하고, repository와 service 계층을 구현을 하고, 이때 HTTP 요청을 처리하는 controller 클래스에서 엔티티를 바로 반환하는 것이다.
보다는,
그래도 DTO로 변환 후 반환하는 방식을 선호한다. 그래서
service에서 entity를 dto로 변환 후 controller에게 반환하여 구현하도록 추천한다.
