(딱히 JPA에 관련된 내용은 아니지만 JPA 강의에서 배운 내용이라 여기에 적는다)
@RequestBody, @ResponseBody를 통해 편리하게 API 통신을 할 수 있다.
이때, 엔티티 객체를 직접적으로 받고, 반환해줘도 단순히 기능을 구현하는 데는 별 문제가 없다.
하지만 이러한 방식은 좋지 않다. "반드시" 엔티티를 그대로 사용하지 말고 DTO를 통해 엔티티의 정보를 전달해야한다.
DTO를 반드시 사용해야 하는 이유는 다음과 같다.
1. DTO를 사용하지 않을 경우 엔티티의 변경에 의해 API 스펙이 변경될 수 있다.
엔티티와 API가 일대일 대응의 관계를 가진다면 엔티티에 수정이 일어날 때마다 API 스펙을 일일히 변경해줘야한다.
이는 매우 번거로운 작업이며 컴파일 에러로 이를 감지할 수 없기 때문에 에러 원인을 찾기가 어렵다.
(DTO를 사용하면 DTO -> 엔티티 과정에서 컴파일 에러가 발생되므로 엔티티의 변경사항을 반드시 파악할 수 있다)
2. 하나의 엔티티에 대해서 API는 여러 개가 존재할 수 있다.
각각의 API가 요구하는 엔티티에 대한 데이터는 모두 다를 확률이 높다.
이때, 그냥 엔티티의 모든 정보를 넘겨줘버린다면 필요없는 데이터까지 받긴 하지만 필요한 건 전부 받은 셈이니 기능 동작에는 문제가 없을 것이다.
하지만 PW처럼 보안상 감추어야 할 정보까지 모두 JSON으로 함께 넘어가기 때문에 보안 문제가 발생할 수 있다.
엔티티 측에서 컬럼에 @JsonIgnore를 사용해 JSON 전달을 막을 수는 있지만 이는 엔티티가 API 스펙에 의존성을 갖게 되므로 좋지 않다.
유지보수가 복잡해질 뿐 아니라 다른 API에 대해서는 그떄그떄 또 변경을 해줘야 하는 쓸 데 없는 번거로움이 발생한다.
3. 엔티티를 그대로 넘겨줄 경우, 엔티티가 가진 정보 외의 것들은 넘겨주지 못한다.
DTO를 사용하면 엔티티의 정보 외에 추가적으로 필요한 정보도 함께 넘겨줄 수 있다.
'김영한님 스프링 강의 정리 > JPA' 카테고리의 다른 글
X to Many 성능 최적화 (fetch join, default_batch_fetch_size) (0) | 2021.04.01 |
---|---|
X to One 성능 최적화 (fetch join) (0) | 2021.04.01 |
JPQL 벌크 연산 (0) | 2021.03.10 |
fetch join의 기능과 한계 (0) | 2021.03.10 |
명시적 조인과 묵시적 조인 (0) | 2021.03.10 |