섹션3 이부터는 본격적인 JPA 사용시 성능 최적화에 대해 다루게 된다.
이때 성능 최적화란 대부분 [조회]의 측면을 이야기 하는데,
왜냐하면 [등록],[수정],[삭제]의 경우는 실제로 단순한 쿼리 한방으로 끝나기 때문에 성능 최적화 관련해서 이야기 할 것이 거의 없기 때문이다.
따라서 이번 [섹션3]에서는 [조희]의 측면에서 아래 3가지 API를 개발하고 최적화를 할 것이다!
1) 주문 조회 API
2) 배송 정보 조회 API
3) 회원 조회 API
그리고 이때의 "최적화"할 이슈는 [지연 로딩] 때문에 나타나므로,
이 [지연 로딩]에 의한 문제를 해결하는 방향을 집중적으로 살펴보자!
먼저 이번 강의에서는 "주문 조회 API" 로써 Order를 조회하는데,
1) [조회]하는 Order를 직접 API Response로 노출하고
2) 이 Order와 양방향 연관관계가 맺어진 다른 Entity들 중, ManyToOne, OneToOne 관계에 놓인 Member와 Delivery가 어떻게 되는지를 살펴보자
(지연 로딩 측면에서)
하지만 결론부터 말하자면, 이번 1강의 내용은 크게 중요하지 않다!
왜냐하면 Entity를 직접 API Response로 노출하는 경우는 거의 거의 없기 때문!!
이번 강의에서 개발할 API
: OrderSearch라는 주문 검색 조건에 따른, 주문 내역 조회 API
- 단 Order라는 Entity를 직접 노출시킨다
/**
* <간단한 주문 조회>
*
* [버전1] : Entity 직접 노출
* - Hibernate5Modile 모듈 등록, LAZY=null 처리
* - 양방향 관계 문제 발생 -> @JsonIgnore
* */
@GetMapping("/api/v1/simple-orders")
public List<Order> ordersV1(){
List<Order> all = orderRepository.findAll(new OrderSearch());
//일부로 지연로딩 된 다른 Entity의 필드에 접근하여 -> 프록시가 아닌 실제 Member와 실제 Delivery Entity를 가져오게 함
for (Order order : all) {
order.getMember().getName();
order.getDelivery().getAddress();
}
return all;
}<위 API에서 나타나는 문제와 해결 방안>
Issue1.
조회한 Order들을 JSON으로 만드는 과정에서, Order와 Member/ Order와 Delivery에 의한 양방향 연관관계로 무한정 JSON이 생성됨.
Issue2.
또한 Order와 연관된 Member와 Delivery는 실제 Entity가 아니고 Proxy 이므로 jackson 라이브러리가 JSON으로 변환시키지 못함.
Solution1.
양방향 연관관계중 한쪽에 @JsonIgnore 어노테이션을 붙여, 객체를 JSON으로 변환시, 이 객체는 JSON변환을 무시해! 라고 말해줘야 한다.
Solution2.
또한 JSON 라이브러리가 Proxy를 변환시키지 못하는 문제를 해결하기 위해,
Hibernate5Module을 스프링 빈으로 등록시키면, Proxy를 JSON으로 변환시키지 않게 된다!
주의할 점.
위 문제가 결국 [지연 로딩]에 의해 나타난다고 해서, [즉시 로딩]을 고려해서는 안된다!
왜냐하면 [즉시 로딩]을 사용할 경우, 조회 시 1+N 문제가 발생하므로 애초에 성능 최적화 할 여지조차 남지 못하게 되기 때문이다.
=> 따라서 [지연 로딩] 사용한 채, 앞으로 배울 성능 최적화를 적용시키는 것이 올바른 방향이다!
