JPA에서 바로 DTO로 조회하여 극한의 최적화를 해보자.

• JPA는 기본적으로 엔티티나 value object만 반환할 수 있다.

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

  • 기본적으로 이렇게 DTO를 반환할 수 없다.

@GetMapping("/api/v4/simple-orders")
public List<OrderSimpleQueryDTO> ordersV4() {
	return orderRepository.findOrderDTOs();
}

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();
}

• 생성자에 일일히 값을 다 넘겨 주어야 한다. 다른 버전 처럼 엔티티를 통으로 넘길 수 없다.

• select 부분이 더 최적화 되었다.
• 그렇다면 v4가 더 좋은 것 아닌가? 우열을 가리기 힘들다. 장단점이 있다.
  • v4는 재사용성이 떨어진다. 화면에 종속 적일 수 있다.
  • v4는 코드가 더 지저분하다.
  • v3는 다른 곳에서도 여러 곳에서 사용될 수 있다.
• 사실 생각보다 성능이 그렇게 차이 나지는 않는다.
• repository에 api 스펙에 맞춘 메소드가 생긴다. api 스펙과 결합이 생긴다.
  • 논란이 있는 부분, repository가 화면에 의존하고 있는 것이다.

만약 데이터 사이즈가 엄청 커서 필드가 20, 30개인 경우, 고객 트래픽이 많은 경우는 고민이 필요하지만 보통 페치 조인을 해도 될 듯하다. 결정 방법은 뒤에서 설명

단점

• repository 재사용성이 떨어지고 api 스펙이 들어가는 문제가 있다.

  • repository는 가급적 순수 엔티티를 조회하는데 써야한다.

  • 해결 방법은?

  • 영한님은 별도의 쿼리용 package, repository를 따로 만든다. 권장 방법

    

    • 통계용, 복잡한 api를 만들어야 할 경우가 실무에 많기 때문에 그런 경우 이런 식으로 뽑아서 관리한다. 그러면 유지 보수성이 좋아진다.

정리

• V3, V4의 장단점이 있다.
• 권장 순서
  • 우선 엔티티를 DTO로 변환한다.
  • 필요하면 페치 조인으로 성능 최적화 (대부분 해결)
  • 그래도 안되면 DTO로 직접조회
  • 최후의 방법은 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다.