간단한 주문 조회V1: 엔티티를 직접 노출

오늘은 가장 중요한 부분 완벽이해! 필

무한루프 멤버에 가면 orders 가 있고 Orders 에는 멤버가 있어서 그렇다.

양방향 연관관계에서 한쪽을 JsonIgnores 해줘야됨

Deliver , Member , OrderItem

이래도 error가 난다.

Order.Class에 지연로딩이 있어서....
프록시 멤버를 생성해서 넣어놓음 (ByteBuddyInterceptor)

멤버 객체에 손대는 순간 멤버 객체를 가져옴 ( 프록시 초기화)

그래서 문제를 어떻게 해결?
지연로딩인 경우 -> 하이버네이트야 제이슨 라이브러리야 아무것도 하지마..

->하이버네이트 파인드 모듈 설치

implementation group: 'com.fasterxml.jackson.datatype', name: 'jackson-datatype-hibernate5'

설치하자 버전정보 안적어놔도 최적버전 다운

null 은 지연 로딩 디비에서 조회한게 아니기 때문에
이런식으로 해결..(근대 중요하지 않다고하네..)

옵션을 넣어주면 지연로딩도 호출해준다.

엔티티를 사용하면 스펙변경시... 큰일남... (추가노출)
성능 문제도 있습니다. (사용하지않는 것도 호출을...)

정리

레이지 로딩때문에 위에 옵션을 쓰면.. 안돼고..
애초에 엔티티를 쓰지말자

옵션안쓸경우 이경우로 해도 제대로 출력된다.

근데 출력 형태가 복잡하다..

데이터를 다노출해버리면 운영하기 어려워진다..

가급적이면 필요한 데이터만 노출시키자..

Dto로 반환하자

V2

그러나 레이지 로딩으로 인한.. 데이터베이스 쿼리가 너무많이 호출된다.

위에 결과는 3개 테이블을 조회한다..

ORDER -> SQL 1번 -> 결과 주문수 2개.
1번째 루프 -> 첫번째 주문에 order에 멤버 조회 delivery 조회
2번째 루프 -> 두번째 주문에 order에 멤버 조회 delivery 조회

쿼리.. 다섯번... order 1 Member 2 Delivery 2

N+1의 문제 . 1+N 문제라 생각해도 될까?

N+1 -> 1 + 회원 N + 배송 N

패치 조인 최적화 V3

페치조인으로 한방에 가져와버리자

단점은 ? 너무 많은 컬럼이..

바로 DTO로 조회

v3 랑 비교.. v4는 재사용성이 없다. 깔끔해지긴하네..

v4는 성능 최적화에는 좋음

v4는 화면 의존적.. 화면이 바뀌면 다뜯어 고쳐야됨..

요즘 성능이 좋아서 둘 사이 성능 차이가 안난다. (Join 에서 성능을 많이 잡아먹지)

v4 같은경우 Repositoy 패키지 안에 따로 패키지 만들어서 모아둔다 성능최적화용

이런식으로..