---

[1] 프록시

우리는 공부할 때 이걸 "왜 써야하지"를 항상 의문으로 가지자.

em.find() VS em.getReference()

em.find(): 데이터베이스를 통해 실제 엔티티 객체를 조회
em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 = DB에 쿼리는 안 나가는데 객체가 조회되는

특징

• 실제 클래스를 상속받아 만들어짐
• 그래서 실제 클래스와 겉 모양이 같음
• 이론상 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨
• 프록시 객체는 실제 객체의 참조(target)를 보관
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출

프록시 객체의 초기화

• 프록시 객체는 처음 사용할 때 한 번만 초기화
• 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님. 초기화되면 프록시 객체를 통해 실제 엔티티에 접근 가능 (프록시가 교체되는 것이 아니라 타겟에만 값이 채워지는 것)
• ⭐️주의 프록시 객체는 원본 엔티티를 상속받기 때문에 타입 체크시 ==대신 instanceof를 사용하자 (프록시가 아닌 멤버랑 프록시 멤버랑 타입이 맞지 않기 때문)
  

• jpa는 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티를 반환한다.
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생한다.
  (하이버네이트는 org.hibernate.LazyInitializationException 예외를 터트림)

프록시 확인

• 프록시 인스턴스의 초기화 여부 확인
  ➡️ PersistenceUnitUtil.isLoaded(Object entity)

• 프록시 클래스 확인 방법
  ➡️ entity.getClass.getName() 출력

• 프록시 강제 초기화
  ➡️ org.hibernate.Hibernate.initialize(entity);

• JPA 표준은 강제 초기화 없음
  강제 호출: member.getName()

---

[2] 즉시 로딩과 지연 로딩

🤷🏻‍♀️ Member를 조회할 때 Team도 조회해야 하나

단순히 member 정보만 사용하는 비즈니스 로직에서 member를 조회했는데 team까지 모두 조회되면 손해이다.

지연 로딩

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)
    // 이렇게 false로 넣어주면 충돌이 발생하지 않고 읽기 전용이 됨
    private Team team;

이렇게 fetch = FetchType.LAZY 해주면 프록시 객체로 조회가 된다.

🤷🏻‍♀️ 그런데 Member와 Team을 자주 같이 조회하게 된다면

즉시 로딩

    @ManyToOne(fetch = FetchType.EAGE)
    @JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)
    // 이렇게 false로 넣어주면 충돌이 발생하지 않고 읽기 전용이 됨
    private Team team;

fetch = FetchType.EAGE
바로 결론을 얘기하자면 즉시 로딩은 사용하지 말자

• 우선, 실무에선 가급적 지연로딩만!! 사용하자.
  (find할 때 다~~~ 끌려나오기 때문에 테이블이 10개쯤 되는 규모가 좀 있는 프로젝트라면 어우,,)
• 즉시로딩은 JPQL에서 N+1문제를 일으킨다.
• @ManyToOne, @OneToOne은 기본이 즉시로딩 → LAZY
• @OneToMany, @ManyToMany는 기본이 지연로딩

지연로딩의 활용

실무에선 무조건 지연 로딩 사용. 아래는 이론적으로..

• Member, Team 자주 함께 사용함 → 즉시 로딩
• Member, Order는 가끔 사용함 → 지연 로딩
• Order, Product는 자주 함께 사용함 → 즉시 로딩
  

📌 모든 연관관계에 지연 로딩을 사용하고 실무에서 즉시 로딩을 사용하지 말자!!

(즉시 로딩은 상상치 못한 쿼리가 발생)
JPQL fetch 조인이나 엔티티 그래프 기능을 사용하자 (추후 설명해주신다고 하심)

---

[3] 영속성 전이(CASCADE)와 고아 객체

영속성 전이: CASCADE

• 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
  Ex. 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장

@OneToMany(mappedBy="parent", cascade=CascadeType.PERSIST)

📌 주의할 점

• 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없으며
  엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐 그 이상, 그 이하도 아니다.

CASCADE의 종류

• ALL: 모두 적용
• PERSIST: 영속
• REMOVE: 삭제
• MERGE: 병합
• REFRESH: refresh
• DETACH: detch

고아 객체

고아객체 제거

: 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제됨

• orphanRemoval = true
• Parent parent1 = em.find(Parent.class, id);
  parent1.getChildren().remove(0);
  ➡️ 자식 엔티티를 컬렉션에서 제거

📌 주의할 점

• 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다.
• 참조하는 곳이 하나일 때 사용해야 한다.
• 특정 엔티티가 개인 소유할 때 사용한다.
• @OneToOne, @OneToMany만 가능

개념적으로 부모를 제거하면 자식은 고아가 된다. 따라서 고아 객체 제거 기능을 활성화하면 부모를 제거할 때 자식도 함께 제거된다.
➡️ CascadeType.REMOVE처럼 동작

영속성 전이 + 고아 객체 생명주기

: CascadeType.ALL + orphanRemovel=true

• 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
• 두 옵션을 모두 활성화하면 부모 엔티티를 통해 자식의 생명 주기를 관리할 수 있다.
• 도메인 주도 설계(DDD)의 Aggregate Root 개념을 구현할 때 유용하다.

---

[4] 실전 예제 5 - 연관관계 관리

실전예제는 jpabook/jpashop 프로젝트로 진행됩니다.
DB: /~/jpashop

글로벌 패치 전략 설정

• 모든 연관관계를 지연 로딩으로
• @ManyToOne, @OneToOne은 기본이 즉시 로딩이므로 지연 로딩으로 변경

영속성 전이 설정

• Order → Delivery를 영속성 전이 ALL 설정
• Order → OrderItem을 영속성 전이 ALL 설정

---