양방향 연관관계와 연관관계의 주인 (Bidirectional associations and masters of associations)
Bidirectional associations and masters of associations
양방향 연관관계와 연관관계의 주인 (Bidirectional associations and masters of associations)
양방향 매핑
객체와 테이블이 관계를 맺는 차이
객체 연관관계 = 2개
회원 -> 팀 연관관계 1개(단방향)
팀 -> 회원 연관관계 1개(단방향)
테이블 연관관계 = 1개
회원 <-> 팀의 연관관계 1개(양방향)
객체의 양방향 관계
객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개다.
객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.
테이블의 양방향 관계
테이블은 외래 키 하나로 두 테이블의 연관관계를 관리
MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐(양쪽으로 조인할 수 있다.)
연관관계의 주인(Owner)
양방향 매핑 규칙
객체의 두 관계중 하나를 연관관계의 주인으로 지정
연관관계의 주인만이 외래 키를 관리(등록, 수정)
주인이 아닌쪽은 읽기만 가능
주인은 mappedBy 속성 사용 X
주인이 아니면 mappedBy 속성으로 주인 지정
주인의 기준
외래 키가 있는 곳을 주인으로 정해라.(N:1 이라면 N을 주인으로)
위의 코드에서는 Member.team이 연관관계의 주인
양방향 매핑시 가장 많이 하는 실수
(연관관계의 주인에 값을 입력하지 않음)
연관관계의 주인에 삽입. ex) member.setTeam(team);
비지니스 로직(메소드)을 통해 양쪽에 다 삽입하는것을 권장.
list의 경우 flush가 발생하지 않는 경우, list(team.members)에 추가된 값은 1차 캐시에는 반영되지 않는다.
이를 위해 flush, clear를 활용하거나, 양쪽에 데이터를 반영하는 방법이 있다.
1가지의 비지니스 로직은 한쪽에만 만드는 것을 권장. -> 오류 발생 방지
양방향 연관관계 주의
순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자.
연관관계 편의 메소드를 생성하자.
양방향 매핑시에 무한 루프를 조심하자.
ex) toString(), lombok, JSON 생성 라이브러리
controller에서는 entity반환 X
보안 문제
API 스팩의 변경을 발생시킨다.
DTO를 통한 반환 권장.
양방향 매핑 정리
단방향 매핑만으로도 이미 연관관계 매핑은 완료
양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
JPQL에서 역방향으로 탐색할 일이 많음
단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨
단방향 매핑이 끝난 경우 양방향 매핑의 추가는 테이블에 영향을 주지 않는다.
-> 설계 단계에서는 단방향 매핑만으로 진행한다.
테이블에 영향을 주지 않음 -> 설계는 단방향만으로 가능
비지니스 로직을 기준으로 연관관계 주인을 선택하면 안된다.
(권장) 연관관계의 주인은 외래 키의 위치를 기준으로 정해야함.
Last updated