연관관계 매핑
데이터 중심 설계의 문제점
- 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
- 테이블의 외래키를 객체에 그대로 가져옴
- 객체 그래프 탐색이 불가능
- 참조가 없으므로 UML도 잘못됨
연관관계 매핑
- 방향(Direction) : 단방향, 양방향
- 다중성(Multiplicity) : 다대일(N:1), 일대다(1:N), 일대일(1:1), 다대다(N:M) 이해
- 연관관계의 주인(Owner) : 객체 양방향 연관관계는 관리의 주인이 필요
객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.
- 테이블을 외래키로 조인을 사용해서 연관된 테이블을 찾는다.
- 객체는 참조를 사용해서 연관된 객체를 찾는다.
- 테이블과 객체 사이에는 이런 큰 간격이 있다.
1:N 관계
Team과 Member 는 1:N 관계이다.
Team을 기준으로 Member와 Team은 1:N 관계이다. 1:N 관계에서 1인쪽은
@OneToMany 애너테이션을 붙여준다.
@OneToMany(mappedBy = "team")
private List<Member> members = new ArrayList<>();Member를 기준으로 Team과 Member는 N:1 관계이다. N:1 관계에서 N인쪽은
@ManyToOne 애너테이션을 붙여준다.
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;Team 클래스에 붙은 mappedBy = "team"은 Member 클래스에 있는 필드 team을 가리킨다.
객체와 테이블이 관계를 맺는 차이
- 객체 연관관계 = 2개
- 회원 -> 팀 연관관계 1개(단방향)
- 팀 -> 회원 연관관계 1개(단방향)
테이블 연관관계 = 1개
- 회원 <-> 팀의 연관관계 1개(양방향)
객체의 양방향 관계
- 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.
- 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다.
- A -> B(a.getB())
- B -> A(b.getA())
테이블의 양방향 연관관계
- 테이블은 외래 키 하나로 두 테이블의 연관관계를 관리
- MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐
(양쪽으로 조인할 수 있다)
연관관계의 주인(Owner)
양방향 매핑 규칙
- 객체의 두 관계중 하나를 연관관계의 주인으로 지정해야 한다.
- 연관관계의 주인만이 외래 키를 관리(등록, 수정)
- 주인이 아닌쪽은 읽기만 가능
- 주인은 mappedBy 속성 사용불가
- 주인이 아니면 mappedBy 속성으로 주인 지정
누구를 주인으로?
- 외래 키가 있는 곳을 주인으로 정한다.
- 1:N 관계에서는 관계가 N인쪽이 연관관계의 주인이 되어야 한다.
양방향 매핑시 가장 많이 하는 실수
(연관관계의 주인에 값을 입력하지 않음)
Member member = new Member();
member.setUsername("member1");
em.persist(member);
Team team = new Team();
team.setName("TeamA");
// 역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);
em.persist(team);이 코드의 문제점은 연관관계의 주인은 Member에 값을 입력하지 않고, Team에만 값을 입력했기
때문에 문제가 생긴다.
양방향 매핑시 연관관계의 주인에 값을 입력해야 한다.
(순수한 객체 관계를 고려하면 항상 양쪽다 값을 입력해야 한다)
Member member = new Member();
member.setUsername("member1");
em.persist(member);
Team team = new Team();
team.setName("TeamA");
// 역방향(주인이 아닌 방향)만 연관관계 설정
team.getMembers().add(member);
// 연관관계의 주인도 연관관계 설정
member.setTeam(team); //**
em.persist(team);연관관계의 주인과 역방향(주인이 아닌 방향)을 연관관계 설정을 하면 문제가 생기지 않는다.
EntityManager에서 flush()와 clear()를 사용하면 연관관계의 주인에만 연관관계를 설정해도
조회시 문제가 되지 않는데, flush()와 clear()를 사용하지 않을때는 문제가 발생한다.
양방향 연관관계 주의
- 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정해야 한다.
- 연관관계 편의 메서드를 생성해야 한다.
- 양방향 매핑시에 무한 루프를 조심해야 한다.
- 예 : toString(), lombok, JSON 생성 라이브러리
연관관계 편의 메서드
연관관계 편의 메서드란, 연관관계의 주인, 또는 역방향에서 값을 넣어주면 양방향에 모두 연관관계를 설정해주도록 엔티티내에서 메서드를 생성하는 것을 말한다.
Member 클래스에서의 연관관계 편의 메서드
public void setTeam(Team team) {
this.team = team;
team.getMembers().add(this);
}Team 클래스를 매개변수로 받아서, 받아온 Team을 set하고, Member 클래스 인스턴스를
Team 클래스에 set 해준다.
Team 클래스에서의 연관관계 편의 메서드
public void addMember(Member member) {
member.setTeam(this);
members.add(member);
}Member 클래스를 매개변수로 받아서, Team 인스턴스를 Member 클래스에 set 해주고,
Team 클래스 내부의 List인 members에 Member 인스턴스를 set 해준다.
이렇게 하면 둘중에 하나의 메서드만 사용해도 양쪽다 값을 셋팅할 수 있다.
어떤 메서드를 사용할지는 실제 애플리케이션을 개발할때 정할 정책이라고 볼 수 있다.
toString()으로 인한 무한루프 문제
자동 완성기능을 이용해서 Member와 Team의 toString() 메서드를 생성하면 다음과 같다.
@Override
public String toString() {
return "Member{" +
"id=" + id +
", username='" + username + '\'' +
", team=" + team +
'}';
}
@Override
public String toString() {
return "Team{" +
"id=" + id +
", name='" + name + '\'' +
", members=" + members +
'}';
} 여기서 메서드 안에 보이는 team은 실제 Team 클래스의 toString()을 호출하고,
members는 Member 클래스의 toString()을 호출하기 때문에, 쌍방으로 무한 호출을 하게되어 무한 루프 상태에 빠져 StackOverFlow가 발생하게 된다.
양방향 매핑 정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료
- 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
- JPQL에서 역방향으로 탐색할 일이 많음
- 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 된다
(테이블에 영향을 주지 않는다)
연관관계의 주인을 정하는 기준
- 비즈니스 로직을 기준으로 연관관계의 주인을 선택하면 안된다.
- 연관관계의 주인은 외래 키의 위치를 기준으로 정해야 한다.
실무에서의 참고 사항
Controller에서 Entity를 JSON으로 반환하지 말고, DTO로 변환해서 반환해야 많은 문제를 막을 수 있다.
출처 : 인프런(자바 ORM 표준 JPA 프로그래밍 기초편)
