실전! 스프링 부트와 JPA 활용 2

---

API 데이터를 운반할땐 Entity가 아닌 Dto를 사용

Entity 와 API 스펙의 분리 (Side Effect 방지)

• API 요청시 해당 스펙을 정확히 알 수 있음
• Entity 를 요청을 받을 때 사용하게 되면 API 각각의 스펙을 정확하게 알기 힘듬
• 각 API마다 유효성 검증을 다르게 할 수 있음
• Entity 전부를 노출시키지 않고 필요한 프로퍼티만 노출

---

쿼리를 위한 함수와 조회를 위한 함수를 따로 사용

• 업데이트 함수(id값 반환까지는 OK)와 조회함수를 따로 두고 사용하면 유지보수가 용이해진다

---

@FetchType을 Lazy로 설정하게 되면 해당 객체를 프록시 객체로 감싸서 넣어 두고 가져다 쓸때 DB에 요청을 함

---

Entity와 연관 관계를 맺고 있는 Entity가 있다면 조회했을 때 N + 1의 문제가 발생

• Member 엔티티 안에 Address 엔티티가 있고 Member를 2개 이상 조회해 왔을 때
• stream을 돌려고 한다면 Member 객체가 바뀔 때마다 Adress 를 조회함
• 1(전체 Member 조회) + N(Member의 수만큼 Address 조회)
• 연관 관계를 맺고 있는 엔티티가 많을 수록 엄청나게 증가함
• => Fetch Join(JPQL)을 이용하여 한 방에 가져오자

---

응답을 할때 단순히 Dto로 감싸지 말고 모든 Entity를 Dto로 변환

• 외부에 Entity 스펙을 노출하면 안 됨

---

컬렉션을 SELECT 할 땐 DISTINCT 키워드를 붙임 (JPQL)

• 데이터베이스의 DISTINCT + 중복 엔티티 제거
• 단점
  • 1:N 관계에서 페이징을 할 때 DB에서 페이징을 하지 않고 메모리에서 페이징을 함(Out of Memory 발생 가능성 높아짐)
  • 두 개 이상의 컬렉션을 Fetch 조인을 할 시 데이터가 부정합하게 조회될 수 있음

컬렉션 페치 조인시 문제점

• 1:N 조인이 발생하므로 데이터가 얘측할 수 없이 증가
• 1:N에서는 1을 기준으로 페이징하는 것이 목적, 하지만 데이터는 N을 기준으로 row가 생성
• Order를 기준으로 페이징하고 싶어도 OrderItem을 조인하면 OrderItem이 기준이 되어버림
• 이 경우 하이버네이트는 경고 로그를 남기고 모든 DB를 읽어 메모리에서 페이징을 시도
  • 최악의 경우 서버 장애로 이어짐

---

컬렉션 페이징하기

• 1:1 관계의 엔티티만 가져오도록 페치 조인을 하고 그 후에 Lazy 로딩
• 먼저 큼직한 것을 퍼오고(1:1 조인) 페이징 그 후 안의 내용물들(1:N)을 퍼옴
• 프로퍼티 설정
  • jpa.properties.hibernate.default_batch_fetch_size = [size]
    • size 만큼 in 조건을 써서 데이터베이스를 조회
• @BatchSize: 엔티티마다 설정

---