💡 데이터 중심 설계의 문제점
- 현재 방식은 객체 설계를 테이블 설계에 맞춘 방식
- 이렇게 하면 협력 관계를 만들 수 없다.
- 테이블의 외래키를 객체에 그대로 가져옴
- 객체 그래프 탐색이 불가능
- 참조가 없으므로 UML도 잘못됨
- 객체 지향적이지 않다.
객체 자체를 참조해야 한다!
💡 단방향 연관관계
연관관계가 필요한 이유?
객체지향 설계의 목표는 자율적인 객체들의 협력 공동체를 만드는 것이다. -조영호
객체 지향 모델링(객체 연관관계 사용)
@Entity
public class Member {
@ManyToOne
@JoinColumn(name = "TEAM_ID")
private Team team;
}💡 양방향 연관관계
Member와 Team은 다대일 관계이다.
Team에서도 Member를 조회할 수 있도록 양방향 연관관계를 맺어준다.
@Entity
public class Team {
@OneToMany(mappedBy = "team")
private List<Member> member = new ArrayList<>();
//add할 때 nullPointerException이 뜨지 않도록 초기화
//member가 team이랑 연결이 되어있다.
}🎈 mappedBy
뭐랑 연결되어있는지 적어주는 것!
객체와 테이블 간 연관관계를 맺는 차이
- 객체 연관관계 : 2개
- 회원 --> 팀(단방향)
- 팀 --> 회원(단방향)
- 테이블 연관관계 : 1개
- 회원 <-> 팀 (양방향. 즉, 방향이 없음)
객체의 양방향 관계
- 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.
- 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야한다.
테이블의 양방향 관계
- 테이블은 외래키 하나로 두 테이블의 연관관계를 관리
- MEMBER.TEAM_ID 외래키 하나로 양방향 연관관계 가짐(양쪽으로 조인 가능)
양방향에서, 둘 중 하나로 외래키를 관리해야한다!
💡 연관관계의 주인
양방향 연관관계에서 나오는 개념
양방향 매핑 규칙
- 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
- 연관관계의 주인만이 외래키를 관리(등록, 수정)
- 주인이 아닌쪽은 읽기만 가능
- 주인은
mappedBy속성 사용 x - 주인이 아니면
mappedBy속성으로 주인 지정
누구를 주인으로?
- 외래키가 있는 곳을 주인으로 정해라(가짜 매핑에다가)
- N쪽이 연관관계의 주인.
- 비즈니스적으로 중요한 것은 아니지만..
💡 양방향 연관관계 주의할 점
- 양항뱡 매핑 시 가장 많이 하는 실수 : 연관관계의 주인에 값을 입력하지 않음
- 순수 객체 상태를 고려해서 항상 양쪽에 값을 설정하자
- 연관관계편의 메소드를 생성하자
- 양방향 매핑시에 무한 루프를 조심하자
- toString(), lombok, JSON
- toString(), lombok, JSON
💡 양방향 매핑 정리
- 단방향 매핑만으로도 이미 연관관계 매핑은 완료!
- 양방향 매핑은 반대 방향으로 조회 기능이 추가된 것 뿐
- JPQL에서 역방향으로 탐색할 일이 많음
- 단방향 매핑을 잘 하고 양방향은 필요할 때 추가해도 됨
(테이블에 영향을 주지 않음)
