public List<SimpleOrderDTO> ordersV2() {
	return orderRepository.findAll(new OrderSearch()).stream()
			.map(SimpleOrderDTO::new)
			.collect(toList());
}

@Data
private static class SimpleOrderDTO {
	private Long orderId;
	private String name;
	private LocalDateTime orderDate;
	private OrderStatus orderStatus;
	private Address address;

	SimpleOrderDTO(Order order) {
		orderId = order.getId();
		name = order.getMember().getName();
		orderDate = order.getOrderDate();
		orderStatus = order.getStatus();
		address = order.getDelivery().getAddress();
	}
}

• DTO 생성자에서 엔티티를 받는 것은 크게 문제가 되지 않는다.

결과

• address는 value object이다. 엔티티가 아니다. 기본편에서 설명한 부분
• lazy 로딩으로 인해 쿼리가 많이 나간다.

  • order, member, delivery

  • 먼저 order 테이블에서 select한다. inner join은 무시해도 된다. 필터링 조건을 쓰려고 했던 것, 회원 이름 같은 것

    

  • 그 다음 member 조회가 lazy로 일어난다.

  • 그 다음 delivery 조회가 lazy로 일어난다.

• 2N + 1 상황이다.
• eager로 튜닝하는 것은 예측이 불가하고 최적화 되지도 않기 때문에 절대 사용하지 말자.
• 만약 member가 같은 경우 영속성 컨텍스트에 데이터 있으니 쿼리를 안날리고 가져오긴 하는데 잘 없는 경우 별로 최적화에 크게 도움은 안될듯 이런 경우 어차피 패치 조인 할거긴 때문