프록시
Member를 조회할 때 Team도 함께 조회해야 할까?
회원과 팀 함께 출력
public void printUserAndTeam(String memberId) {
Member member = em.find(Member.class, memberId);
Team team = member.getTeam();
System.out.println("회원 이름: " + member.getUsername());
System.out.println("소속팀: " + team.getName());
}
회원만 출력
public void printUser(String memberId) {
Member member = em.find(Member.class, memberId);
Team team = member.getTeam();
System.out.println("회원 이름: " + member.getUsername());
}
프록시 기초
- em.find() : 데이터베이스를 통해서 실제 엔티티 조회
- em.getRerence() : 데이터베이스 조회를 미루는 가짜 엔티티(프록시) 객체 조회
프록시 특징1
- 실제 클래스를 상속받아서 만들어짐
- 실제 클래스와 겉모양이 같다
- 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨.
- 프록시 객체는 실제 객체의 참조를 보관
- 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출
프록시 특징2
- 프록시 객체는 처음 사용할 때 한 번만 초기화
- 프록시 객체를 초기화 할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근
- 프록시 객체는 원본 엔티티를 상속 받음, 따라서 타입 체크 시 주의해야 함 (== 비교 실패, 대신 instance of 사용)
- 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
- 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 에러 발생.
즉시 로딩과 지연 로딩
지연 로딩
상황 ) 단순히 member 정보만 사용하는 비즈니스 로직, Member를 조회할 때 Team도 함께 조회해야 할까?
지연 로딩 LAZY을 사용해서 프록시로 조회
@Entity
public class Member {
@Id
@GeneratedValue
private Long id;
@Column(name = "USERNAME")
private String name;
@ManyToOne(fetch = FetchType.LAZY) //**
@JoinColumn(name = "TEAM_ID")
private Team team;
..
}
Team team = Member.getTeam();
team.getName(); // 실제 team을 사용하는 시점에 초기화(DB조회)
즉시 로딩
상황) Member와 Team을 자주 함께 사용한다면?
즉시 로딩 EAGER를 사용해서 함께 조회
@Entity
public class Member {
@Id
@GeneratedValue
private Long id;
@Column(name = "USERNAME")
private String name;
@ManyToOne(fetch = FetchType.EAGER) //**
@JoinColumn(name = "TEAM_ID")
private Team team;
..
}
프록시와 즉시 로딩 주의
- 가급적 지연 로딩만 사용 (특히 실무에서!!)
- 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생 => 명시적으로 호출하는 것이 아니라 자동으로 호출되는 것이라 개발자 입장에서 혼동을 줌.. 코드만 보고 즉 관적으로 판단하기 어려움.. 디버깅하려면 Entity 클래스 다 까봐야됌
- 즉시 로딩은 JPQL에서 N+1문제를 일으킨다.
- @ManyToOne, @OneToOne은 기본이 즉시 로딩=> LAZY로 설정!!
- @OneToMany, @ManyToMany는 기본이 지연 로딩
영속성 전이 : CASCADE
- 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음
- 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐.
종류
- ALL : 모두 적용
- PERSIST : 영속
- REMOVE : 삭제
- MERGE : 병합
- REFRESH
- DEFACH
고아 객체
- 고아 객체 제거: 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제
- 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개념을 구현할 때 유용
'Spring Data' 카테고리의 다른 글
JPQL 기본 문법 (0) | 2021.08.09 |
---|---|
값 타입 #9 (0) | 2021.07.26 |
고급매핑 #7 (0) | 2021.07.23 |
다양한 연관관계 매핑 #6 (0) | 2021.07.19 |
연관관계 매핑 기초 #5 (0) | 2021.07.18 |