22.06.24

주문 조회 V4: JPA에서 DTO 직접 조회

* 리포지토리 패키지 분리 : 관심사가 다름 *

기본 리포지토리: 엔티티 조회. List<Entity> 반환

쿼리 리포지토리: 프레젠테이션 API에 의존관계가 있는 데이터 조회. List<EntityDto> 반환

 

쿼리 리포지토리가 EntityDto를 의존하고 있기 때문에 정의하는 위치 주의

"컨트롤러->서비스->리포지토리"의 단방향 의존관계가 깨지지 않도록 리포지토리 이하에 정의

컨트롤러와 연관된 Dto라고 컨트롤러 쪽에 정의하면 컨트롤러->리포지토리->컨트롤러의 의존관계 순환 발생

 

1. new 연산자를 사용하여 컬렉션을 제외하고 매핑하여 EntityDto.class로 조회

*new 연산자는 sql을 사용하는 것과 유사. flat한 조회만 가능 (컬렉션 불가)

2. 조회한 리스트에 대해 루프를 돌리면서 외래키를 꺼내서 컬렉션에 대해 EntityDto2.class로 조회

*OrderItem과 Item은 OneToOne이기 때문에 join해도 데이터가 증가하지 않는다.

 

결과적으로 N+1 쿼리 문제

주문 조회 V5: JPA에서 DTO 직접 조회 - 컬렉션 조회 최적화

1. V3 과 동일

2. 외래키 리스트를 IN 절에 파라미터로 넣어 한 번에 필요한 데이터를 모두 가져온다.    메모리 환경에서 비어있던 컬렉션 필드에 값을 세팅 (+MAP을 사용해서 매칭 성능 향상 (O(1))

주문 조회 V6: JPA에서 DTO로 직접 조회, 플랫 데이터 최적화

1. flat한 데이터 구조의 DTO로 모든 엔티티 join하여 한 번에 조회 -> 중복O, 페이징 불가

2. 메모리 상에서 중복 제거

 

쿼리 1번, 일대다에서 일 기준 페이징 불가

애플리케이션에서 추가 작업이 크다.

 

*다음 에러로 이동: F2