[JPA] 연관관계 매핑 기초

- 연관관계의 주인이라는 개념은 양방향 연관관계에서만 사용되는 개념이다. (테이블은 외래키로 테이블을 조인하기 때문에 방향이라는 개념이 없음)

- 연관관계의 주인만이 외래 키를 관리(등록, 수정)하고 주인이 아닌 쪽은 읽기만 가능하다

- 주인이 아니면 mappedBy 속성으로 주인 지정

- 실제로 연관관계의 주인쪽만 세팅을 해도 db에 제대로 반영되지만 트랜잭션 커밋전에 연관관계의 주인이 아닌 쪽에서 데이터를 가져오는 경우 1차 캐시에서 데이터를 가져오게 되고 이 경우에는 데이터 세팅이 되어 있지 않기 때문에 양방향 연관관계 편의 메서드를 이용하여 양쪽 모두 세팅하는 것이 순수 객체 관점에서는 적합하다. (데이터를 변경하는 경우 리스트쪽에서는 기존 값을 삭제하고 새로운 값을 추가하는 등을 고려해야 한다.)

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
Public class Team {
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
    
	public void addMember(Member member) {
    	if(member.getTeam() != null) { // 기존의 팀이 있다면 삭제
        	member.getTeam().getMembers().remove(member);
        }
        member.setTeam(this);
        this.getMembers().add(member);
    }
}

- 위의 코드처럼 연관관계 매핑의 주인이 아닌 쪽은 new ArrayList<>();로 해주는 것이 관례이다. (NPE 방지)

- 위의 코드의 양뱡향 연관관계 매핑 편의 메서드에서 기존의 팀이 있다면 삭제하는 부분이 있는데 순수 객체 관점에서는 이 방식이 적합한게 맞지만 JPA 관점에서 저렇게 하지 않아도 db에는 의도한대로 적용이 된다.(멤버쪽에서 팀만 바꾸고 db에 적용한 뒤 team.getMembers()를 하게 되는 경우 해당 팀 id로 member들을 조회하는 쿼리가 날라가기 때문에 굳이 members에서 remove 할 필요가 없음)

- 엔티티를 그대로 반환하게 되면 양방향 연관관계에 의한 무한 루프와 엔티티 수정 시 api 스펙이 변경되는 문제 등이 발생할 수 있기 때문에 되도록이면 dto 클래스를 사용하자!

 

 

 

결론

- 단방향 매핑만으로도 연관관계 매핑하는데 문제는 없지만 JPQL 등으로 조회할 때 조회의 편의와 객체지향적인 애플리케이션 개발에 있어서 양방향 매핑을 고려하는 것이 좋다.

 

 

출처: 인프런 김영한님의 자바 ORM 표준 JPA 프로그래밍 - 기본편

https://www.inflearn.com/course/ORM-JPA-Basic

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의