엔티티를 파라미터로 사용할 때
🖊 엔티티의 의존성을 줄이기 위해
엔티티의 필드 명을 수정하는 경우가 발생했을 때 관련된 모든 API를 수정해야한다.(Side effect)
컨트롤러에서 입력받는 값에 제약을 걸 때 양방향 매핑 관계로 엔티티에 영향이 간다. (@NoEmpty 등)
엔티티를 반환 값으로 사용할 때
🖊 가공하기 위해
API에서 엔티티를 그대로 반환하는 것 또한 여러 문제점을 야기한다.
각 API마다 필요한 필드가 다른데 엔티티는 1개인 상황에서 DTO를 사용하지 않고 해결할 방법은
필드에 JSON ignore같은 방법으로 뺄 수 밖에 없다.
이또한 근본적인 해결책이 되지 못하며 엔티티가 역으로 api에 의존하는 상황이 발생한다.
또한 엔티티를 그대로 반환하기 때문에 확장의 유연성 또한 매우 떨어진다.
🖊 JPA 지연 로딩 방식 때문에
엔티티를 그대로 반환하면 필요한 필드만 반환되는 것이 아니기 때문에
해당 엔티티가 가지고있는 연관된 엔티티 또한 같이 반환되는데,
이때 연관된 엔티티를 쓰지 않으므로 JPA는 프록시 객체로 채워놓은 상태다.
이를 그대로 반환하려하면 실제 객체와 프록시 객체의 Type이 맞지 않기 때문에
이를 해결하려하면 API를 위해 엔티티에 영향이 가는 상황이 마찬가지로 발생한다.
또한 성능 최적화도 어렵다.(N+1)
.jpg)