[API] API 고급 설계 - 지연 로딩과 조회 성능 최적화

❌ 엔티티 직접 노출

    @GetMapping("/api/v1/orders")
    public List<Order> ordersV1() {
        List<Order> all = orderRepository.findAll();
        for (Order order : all) {
            order.getMember().getName(); //Lazy 강제 초기화
            order.getDelivery().getAddress(); //Lazy 강제 초기화
            List<OrderItem> orderItems = order.getOrderItems();
            orderItems.stream().forEach(o -> o.getItem().getName()); //Lazy 강제 초기화
        }
        return all;
    }

• order member 와 order address 는 지연 로딩이다. 따라서 실제 엔티티 대신에 프록시 존재
• jackson 라이브러리는 기본적으로 이 프록시 객체를 json으로 어떻게 생성해야 하는지 모름 예외 발생
• [해결방안]
• Hibernate5Module 모듈(스프링 빈) 등록, LAZY=null 처리
• 양방향 관계 문제 발생 -> @JsonIgnore로 해결

[하이버네이트 모듈 등록]
스프링 부트 버전에 따라서 모듈 등록 방법이 다르다.
스프링 부트 3.0 부터는 javax -> jakarta 로 변경 되어서 지원 모듈도 다른 모듈을 등록해야 한다.
스프링 부트 3.0 미만: Hibernate5Module 등록 build.gradle 에 다음 라이브러리를 추가하자
implementation 'com.fasterxml.jackson.datatype:jackson-datatype-hibernate5' JpashopApplication 에 다음 코드를 추가하자 ...(더보기) P.15

 

❌ 엔티티를 조회해서 DTO로 변환(fetch join 사용X)

    @GetMapping("/api/v2/orders")
    public List<OrderDto> ordersV2() {
        List<Order> orders = orderRepository.findAll();
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(toList());

        return result;
    }

• • 엔티티를 DTO로 변환하는 일반적인 방법이다.
  • 쿼리가 총 1 + N + N번 실행된다. (v1과 쿼리수 결과는 같다.)
    • order 조회 1번(order 조회 결과 수가 N이 된다.)
    • order -> member 지연 로딩 조회 N 번
    • order -> delivery 지연 로딩 조회 N 번
    • 예) order의 결과가 4개면 최악의 경우 1 + 4 + 4번 실행된다.(최악의 경우)
      • 지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략한다.

//OrderSimpleApiController - 추가
@Data
static class SimpleOrderDto {
     private Long orderId;
     private String name;
     private LocalDateTime orderDate; //주문시간
     private OrderStatus orderStatus;
     private Address address;
     
/*     public SimpleOrderDto(Order order) {
         orderId = order.getId();
         name = order.getMember().getName();
         orderDate = order.getOrderDate();
         orderStatus = order.getStatus();
         address = order.getDelivery().getAddress();
 	}*/
    
     public SimpleOrderDto(Long orderId, String name, LocalDateTime orderDate, 
     						OrderStatus orderStatus, Address address) {
         this.orderId = orderId;
         this.name = name;
         this.orderDate = orderDate;
         this.orderStatus = orderStatus; 
         this.address = address;
     }
}

 

✅  엔티티를 조회해서 DTO로 변환(fetch join 사용O)

    @GetMapping("/api/v3/orders")
    public List<OrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithItem();
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(toList());

        return result;
    }

• 엔티티를 페치 조인(fetch join)을 사용해서 쿼리 1번에 조회
• 페치 조인으로 order -> member , order -> delivery 는 이미 조회 된 상태 이므로 지연로딩X
• 실무에서 무조건 fetch조인 사용하기
• 여러 테이블을 연결한 긴 로우를 찾게되는데 JPA가 적절히 잘라줌(다음 단계에서 이부분 최적화)

//OrderRepository - 추가 코드
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();
}

 

 

 

✅ JPA에서 DTO로 바로 조회

    @GetMapping("/api/v4/orders")
    public List<OrderQueryDto> ordersV4() {
        return orderQueryRepository.findOrderQueryDtos();
    }

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

//OrderSimpleQueryRepository 조회 전용 리포지토리

@Repository
@RequiredArgsConstructor
public class OrderSimpleQueryRepository {
     private final EntityManager em;
     public List<OrderSimpleQueryDto> findOrderDtos() {
         return em.createQuery(
                 "select new 
                jpabook.jpashop.repository.order.simplequery.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();
     }
}

 

 

V3와 V4는 우위를 가릴 수 없음.
V4가 간결하게 가져오지만 재사용성이 떨어짐
V3는 엔티티를 조회했기 때문에 비즈니스 로직에 써서 데이터 변경 가능V4는 DTO조회이기 때문에 데이터 변경할 수 없음(엔티티 아니므로)

엔티티를 DTO로 변환하거나, DTO로 바로 조회하는 두가지 방법은 각각 장단점이 있다. 둘중 상황에 따라 서 더 나은 방법을 선택하면 된다. 엔티티로 조회하면 리포지토리 재사용성도 좋고, 개발도 단순해진다. 따라 서 권장하는 방법은 다음과 같다

쿼리 방식 선택 권장 순서
1. 우선 엔티티를 DTO로 변환하는 방법을 선택한다.
2. 필요하면 페치 조인으로 성능을 최적화 한다. 대부분의 성능 이슈가 해결된다.
3. 그래도 안되면 DTO로 직접 조회하는 방법을 사용한다.
4. 최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사 용한다.