Shoot for the moon!

앞으로 4개의 포스팅에 걸쳐서 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결해보겠습니다. 오늘은 첫 번째 시간으로 V1(버전 1)에 대해서 정리하고 문제점과 주의점 그리고 대안에 대해서 정리해보겠습니다. 추천드리는 방법은 아니기 때문에 가볍게 보시면 될 것 같습니다. 결론 : 엔티티를 직접 노출하지 말자! 간단한 주문 조회 V1 : 엔티티를 직접 노출 주문(Order) + 배송정보(Delivery) + 회원(Member)을 조회하는 API를 만들어보겠습니다. OrderSimpleApiController package jpabook.jpashop.api; import jpabook.jpashop.domain.Order; import jpabook.jpashop.repository.OrderRepo..

프록시 포스팅에 이어서 즉시 로딩과 지연 로딩의 주제로 넘어가 보겠습니다. 지연 로딩 LAZY를 사용해 프록시로 조회 @Entity public class Member{ ... @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "TEAM_ID") private Team team; ... } member 조회 시 (team을 Join하지 않고) member만 조회 쿼리 나가고 team 객체는 Proxy 객체로 생성됨. 이후실제로 team을 사용하는 시점에 초기화(DB 조회) 되면서 쿼리 나감 만약 Member와 Team을 자주 함께 사용한다면, 즉시 로딩 EAGER를 사용해 함께 조회 @Entity public class Member { ... @ManyToO..

프록시는 그 자체의 개념뿐만 아니라 즉시 로딩, 지연 로딩을 온전히 이해하기 위해 알아두어야 하는 개념입니다. 프록시를 왜 써야 하는지부터 차근차근 알아보도록 하겠습니다. 프록시를 왜 써야 하는가? Member를 조회할 때 Team도 함께 DB에서 조회해야 할까? Team을 사용하지 않는 경우 = Team까지 조회를 하는 것은 리소스의 손해이다 해결 : 프록시를 써서 지연로딩을 이용하면, 실제 필요할 때 Team을 DB에서 조회하여 리소스를 절약할 수 있다. 프록시 em.find() vs em.getReference() em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 DB에 쿼리가 안 나가는데 객..