13.2.2 JPQL 페치조인

페치조인을 사용하게 되면 SQL JOIN을 사용해서 페치조인 대상까지 함께 조회한다. 따라서 N+1문제가 발생하지 않는다.

-> 페치조인은 N+1문제를 해결하면서 화면에 필요한 엔티티를 미리 로딩하는 현실적인 방법이다.

 

JPQL 페치조인의 단점

페치조인이 현실적인 대안이긴 하지만, 무분별하게 사용하면 화면에 맞춘 리포지토리 메소드가 증가할 수 있다. 결국 프리젠테이션 계층이 알게 모르게 데이터 접근 계층을 침범하는 것이다. 

 

- 화면 A를 위해 order만 조회하는 repository.findOrder() 메소드

- 화면 B를 위해 order와 연관된 member를 페치조인으로 조회하는 repository.findOrderWithMember 메소드

 

13.2.3 강제로 초기화

강제로 초기화하기는 영속성 컨텍스트가 살아있을 때 프리젠테이션 계층이 필요한 엔티티를 강제로 초기화해서 반환하는 방법.

 

class OrderService {

  @Transactional
  public Order findOrder(id) {
     Order order = orderRepository.findOrder(id);
     order.getMember().getName(); //프록시객체를 강제로 초기화한다.
     return order;
  }
}

하이버네이트를 사용하면 initalize 메소드를 사용하여 프록시를 강제로 초기화 할 수 있다.

 

프록시를 초기화하는 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야한다. 프리젠테이션 계층이 서비스 계층을 침범하는 상황이다. 서비스계층은 비즈니스 로직을 담당해야지 이렇게 프리젠테이션 계층을 위한 일까지 하는 것은 좋지 않다. 따라서 비즈니스 로직을 담당하는 서비스 계층에서 프리젠테이션 계층을 위한 프록시 초기화 역할을 분리해야 한다

-> FACADE 계층이 그 역할을 담당한다.