자바 ORM 표준 JPA 프로그래밍 공부 기록
💡 JPA의 목적
객체 지향 프로그래밍과 DB 사이의 패러다임 불일치를 해결
즉, 객체와 관계형 DB 테이블이 어떻게 매핑되는지를 이해하는 것이 가장 중요하다!
💡 연관관계가 필요한 이유
객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력 관계를 만들 수 없다.
- 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
- 객체는 참조를 사용해서 연관된 객체를 찾는다.
=> 연관된 데이터를 조회할 때 객체는 참조를 사용하지만, 테이블은 조인을 이용한다.
💡 연관 관계 정의 규칙
관계 매핑 시, 주의해야 할 것 3가지
-
방향
단방향, 양방향 -
연관 관계의 부모
연관 관계에서 관리의 주체 -
다중성
N:1, 1:N, 1:1, N:M
📍 단방향, 양방향
Database의 테이블은 FK 하나로 두 개의 테이블의 JOIN이 가능하다.
그러나 객체의 경우 참조용 필드가 있는 객체만 다른 객체를 참조하는 것이 가능하다. 그렇기 때문에 두 객체 사이에 하나의 객체만 참조용 필드를 갖고 참조하면 단방향 관계, 두 객체 모두가 각각 참조용 필드를 갖고 참조하면 양방향 관계라고 한다.
비즈니스 로직에서 두 객체가 참조가 필요한지 여부를 고민하여 관계를 설정하면 된다.
❓ 무조건 양방향 관계로 한다면?
모든 엔티티를 양방향 관계로 설정하게 되면, 엄청나게 많은 테이블과 연관 관계를 맺게 되고 클래스가 굉장히 복잡해진다. 그리고 다른 엔티티들도 불필요한 연관관계 매핑으로 인해 복잡성이 증가할 수 있으므로 양방향인지 단방향인지 필히 구분 해 주어야 한다.
기본적으로 단방향으로 매핑하고 나중에 역방향으로 객체 탐색이 필요하다고 느낄 때 추가하는 것도 좋은 방법이다.
📍 연관 관계의 부모
@OneToMany만 있으면 되지, MappedBy는 왜 필요할까?
객체에는 양방향 연관관계라는 것이 없다. 서로 다른 단방향 연관관계 2개를 애플리케이션 로직으로 잘 묶어서 양방향인 것 처럼 보이게 할 뿐이다.
반면, 데이터베이스 테이블은 외래 키 하나로 양쪽이 서로 JOIN할 수 있다. 따라서 테이블은 외래 키 하나로 양방향 연관관계를 맺는다.
=> 테이블은 외래 키 하나로 두 테이블의 연관 관계를 관리한다.
- 엔티티를 양방향 관계로 설정하면 객체의 참조는 둘인데, 외래 키는 하나이다.
- 둘 중 어떤 관계를 사용해 외래 키를 관리할 것인가? => 연관관계의 주인
- 연관관계의 주인은 테이블에 외래 키가 있는 곳 (Many 쪽)
연관관계의 주인만이 데이터베이스의 연관관계와 매핑되고 외래 키를 관리할 수 있다. 주인이 아닌 쪽은 읽기만 가능하다.
연관관계의 주인을 정할 때는 mappedBy를 사용한다.
- 주인은 mappedBy 속성을 사용하지 않는다.
- 주인이 아닌 쪽은 mappedBy 속성을 이용하여 연관관계의 주인을 지정한다.
이론 상 연관관계 주인 쪽에만 연관관계를 맺은 객체를 넣어주면 되지만, 순수한 객체 관계를 고려했을 때는 양쪽 객체에 모두 값을 입력 해주어야 한다.
=> 연관관계 편의 메소드를 생성하자
public void changeTeam(Team team){
this.team = team;
team.getMembers().add(this);
}한 번에 양방향 관계를 설정하는 메소드 = 연관관계 편의 메소드
❓Controller에서 Entity를 반환하면 안 되는 이유
- 무한루프 문제
- Entity는 충분히 변경 가능하다. 이를 API 반환해버리면 API 스펙 자체가 변경되는 문제가 생길 수 있다. API는 반드시 DTO로 반환해야한다~
📍결론
- 단방향 매핑만으로도 이미 연관관계 매핑이 완료되었다
- 양방향 매핑은 반대 방향으로 조회 기능이 추가된 것 뿐이다.
- 단방향 매핑을 잘하고 양방향은 필요할 때 추가하면 된다.
- 비즈니스 로직을 기준으로 연관관계의 주인을 선택하면 안된다. 연관관계의 주인은 외래 키의 위치를 기준으로 정해야한다.
- 단방향 설정만 잘하자~
