Respository
public List<Order> findAllWithMemberDelivery() {
return em.createQuery(
"select o from Order o"+
" join fetch o.member m" +
" join fetch o.delivery d ",Order.class
).getResultList();
}
Query

Respository (DTO 사용한 버전)
public List<OrderSimpleQueryDto> findOrderDtos() {
return em.createQuery(
"select new jpabook.jpashop.repository.OrderSimpleQueryDto(o.id, m.name,o.orderDate,o.status, d.address) from Order o"+
" join o.member m"+
" join o.delivery d", OrderSimpleQueryDto.class)
.getResultList();
}
Query

- 일반적인 SQL을 사용할 때 처럼 원하는 값을 선택해서 조회
- new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환
- SELECT 절에서 원하는 데이터를 직접 선택하므로 DB 애플리케이션 네트웍 용량 최적화(생각보다 미비)
- 리포지토리 재사용성 떨어짐, API 스펙에 맞춘 코드가 리포지토리에 들어가는 단점
💡 PostMan 결과는 똑같지만 쿼리가 다른 걸 알 수 있다

정리
엔티티를 DTO로 변환하거나, DTO로 바로 조회하는 두가지 방법은 각각 장단점이 있다.
둘중 상황에 따라서 더 나은 방법을 선택하면 된다.
엔티티로 조회하면 리포지토리 재사용성도 좋고, 개발도 단순해진다.
쿼리 방식 선택 권장 순서
- 우선 엔티티를 DTO로 변환하는 방법을 선택한다.
- 필요하면 페치 조인으로 성능을 최적화 한다. 대부분의 성능 이슈가 해결된다.
- 그래도 안되면 DTO로 직접 조회하는 방법을 사용한다.
- 최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다.
'TIL' 카테고리의 다른 글
| [JPA] API 개발 고급 정리 (1) | 2023.03.21 |
|---|---|
| [JPA] 페이징과 한계돌파 (0) | 2023.03.20 |
| [JPA] N+1 문제 (0) | 2023.03.19 |
| [JPA] DTO 설계 이유 (0) | 2023.03.18 |
| [JPA] Entitiy 대신 ResponseDto,RequestDto 사용, 그 이유 (0) | 2023.03.17 |