JPA에서 DTO 직접 조회 vs entity를 DTO로 반환

두 가지 방식 비교

1. 일반적으로 순수 Entity를 반환하는 OrderRepository에서 아래와 같이 entity를 반환하여 Service계층에서 responseDto로 변환하여 응답하는 방법이 있다.
   

2. OrderQueryRepository는 화면에 최적화된 쿼리 전용 Repository이다.
   
   위의 사진과 같이 JPA에서 Dto로 직접 조회해 오는 방식도 있다.
   위의 코드는 DTO로 매핑하는 부분이 너무 더럽다. 이 부분은 QueryDSL로 깔끔하게 작성할 수 있다고 한다.

각 방식의 장단점 비교

1번 방식의 특징
1. 영속성 컨텍스트에서 관리되어 엔티티의 변경 추적, 지연 로딩 등의 이점을 활용할 수 있다.
2. 객체 그래프 탐색: 연관된 엔티티를 탐색하고 필요한 데이터를 가져올 수 있다.
3. 다른 메소드에서 재사용성이 높다.

2번 방식의 특징
1. view에 맞춰있어, 필요한 데이터만 선택하여 DTO로 매핑하므로 최소한의 데이터만 효과적으로 가져올 수 있다.
2. select로 딱 필요한 필드만 가져오기 때문에, 불필요한 데이터를 가져오지 않아 네트워크 비용을 줄이고, 쿼리 성능이 향상 될 수 있다.
3. 반면에 2번과 같이 DTO를 직접 조회하는 방식은 성능을 최적화 하거나, 성능 최적화 방식을 변경할 때 많은 코드를 변경해야 한다.

권장 순서

1. 엔티티 조회 방식으로 우선 접근한다.
   1. fetch join으로 쿼리 수를 최적화한다.
   2. 컬렉션 최적화
      1. 페이징이 필요하면, @Batchsize로 최적화
      2. 페이징 필요하지 않으면 -> fetch join 사용한다.
2. 엔티티 조회 방식으로 해결이 안되면 DTO 조회방식을 사용한다.(Query 전용 Repository를 따로 만들어 관리하는게 좋다.)
3. DTO 조회 방식으로 해결이 안되면 NativeSQL or 스프링 JdbcTemplate을 사용한다.

참고
개발자는 성능 최적화와 코드 복잡도 사이에서 줄타기를 해야 한다. 항상 그런것은 아니지만, 보통 성능 최적화는 단순한 코드를 복잡한 코드로 몰고 간다.
엔티티 조회 방식은 JPA가 많은 부분을 최적화 해주기 때문에, 단순한 코드를 유지하면서, 성능을 최적화 할 수 있다.
반면에, DTO 조회 방식은 SQL을 직접 다루는 것과 유사하기 때문에, 둘 사이에서 줄타기를 해야한다.