JPA 프로그래밍 입문 - chapter 12 연관 잘 쓰기

1. 연관의 복잡성

1.1 로딩 설정의 어려움

  • 일관적으로 모든 연관에 즉시 로딩을 적용하진 않는다. 엔티티를 어떤 식으로 사용할지 미리 고민해서 지연로딩과 즉시로딩을 적절하게 적용해야 한다.
  • 상황에 따라 필요한 연관 객체가 다르기 때문에 특정 연관을 지연 로딩이나 즉시 로딩으로 한정할 수 없다.

1.2 편리한 객체 탐색과 높은 결합도

  • 모든 엔티티를 연관으로 연결하면 객체 탐색을 통해서 쉽게 원하는 객체에 접근할 수 있다.
  • 한 엔티티에서 다른 엔티티와 연관을 맺고 다른 엔티티의 메소드 등을 실행하면 엔티티가 서로 강하게 엮이게 되면서 서로 수정을 어렵게 만드는 원인이 될 수 있다.

2. 연관 범위 한정과 식별자를 통한 간접 참조

  • 엔티티 간의 참조가 많아질수록 한 엔티티의 기능을 변경할 때 여러 엔티티를 함께 수정해야 할 가능성이 커진다. 이는 코드 변경을 어렵게 만드는 원인이 될 수 있다.
  • 다음 두가지 규칙을 생각하면서 연관을 적용하는게 좋다.
    • 연관의 범위를 도메인 기준으로 한정
    • 도메인을 넘어서는 엔티티간에는 식별자를 이용한 간접 참조 사용
public class Order {
    
    private List<OrderLine> orderLines; // 영역 내 모델은 직접참조
    private String userId;              // 영역 밖의 엔티티는 식별자로 참조
    
    ...
}
  • 식별자를 통한 간접 참조 방식을 사용하면 식별자로 연관된 엔티티를 검색하는 과정이 추가된다. 하지만 식별자를 통한 간접 참조를 사용하면 “로딩 설정의 어려움”, “엔티티 간의 결합도 증가” 문제를 완화할 수 있다.

3. 상태 변경 관련 기능과 조회 관련 기능

  • 연관을 한정해서 사용하면 설정이나 코드 복잡도가 줄어드는 장점이 있다. 하지만 데이터를 조회할 때 여러 엔티티를 직접 조회해야 하는 불편함도 있다.
  • 위와 같은 문제를 해결하는 방법 중 하나는 상태를 변경하는 기능과 조회하는 기능을 분리해서 생각하는 것이다.
  • 상태 변경 기능은 한 두개의 엔티티만 로딩하기 때문에 식별자를 사용해서 간접 참조했을 때 장점이 더 크다.
  • 조회 관련 기능은 한 개 이상의 엔티티를 함께 조회하는 경우가 많다. 여러 엔티티의 데이터를 조합해야 하는 조회 기능은 조회 기능에 맞는 모델을 따로 구현하는 것을 고려해보면 좋다.
  • 도메인이 커질수록 한 개의 모델로 상태 변경 기능과 조회 기능을 구현하기 어려워진다. 로딩 방식 문제뿐만 아니라 상태 변경 시점과 조회 시점에 필요한 데이터가 다르기 때문이다.
    • 조회 시점에 필요한 데이터와 변경 시점에 다루는 데이터의 차이가 클수록 조회 전용 모델을 별도로 만들 것을 고려해봐야 한다.

4. 식별자를 공유하는 1:1 연관이 엔티티와 밸류 관계인지 확인

  • 한 도메인 영역에 속하면서 식별자 공유 방식으로 1:1 연관을 맺는 두 엔티티가 동일한 라이프사이클을 갖는다면 이 관계는 두 엔티티의 1:1 연관이 아닌 엔티티와 밸류 관계일 가능성이 크다.
@Entity
@SecondaryTable(
	name = "appeal_status",
    pkJoinColumns = @PrimaryKeyJoinColumn(
    	name = "id",
        referencedColumnName = "id"
    )
)
public class Appeal {
    @Id
    private String id;
    @Embedded
    private AppealStatus status;
    ...
}

@Embeddable
public class AppealStatus {
    @Id
    private String id;   
    ...
}
  • 식별자를 공유하는 두 엔티티의 1:1 연관은 두 테이블을 사용하는 엔티티-밸류 관계인지 확인할 필요가 있다.

5. 엔티티 콜렉션 연관과 주의 사항

  • 1:N 단방향 연관, 양방향 연관은 코드를 더 복잡하게 만든다.

5.1 1:N 연관보다 N:1 연관 우선

  • 1:N 연관을 사용할 때 주의할 점은 N에 해당하는 부분을 실제 기능에서 어떤 식으로 사용하는지 알아야 한다는 점이다. 만약 1:N 연관에서 콜렉션에 보관된 엔티티를 일부만 사용한다면 N:1 연관을 대신 사용하는게 좋다. 왜냐하면 일부만 사용하더라도 1:N 연관에서는 전체 데이터를 로딩하기 때문에 성능 문제가 발생할 수 있기 때문이다.
  • 1:N 연관이 더 단순하기 때문에 연관으로 인해 발생하는 코드의 복잡함도 줄여준다.

5.2 엔티티 간 1:N 연관과 밸류 콜렉션

  • 1:N 연관에서도 엔티티에 대한 콜렉션이 아니라 밸류에 대한 콜렉션이 적합할 때가 있다. 단순히 테이블이 따로 존재한다고 해서 엔티티 간의 1:N 연관으로 매핑하는 것은 옳지 않다. 1:N 연관이 필요하다면 해당 연관이 엔티티 간의 연관인지 밸류 콜렉션인지 검토해야한다.
  • 한 도메인 영역에 속하면서 1:N 연관을 맺는 엔티티가 동일한 라이프사이클을 갖는다면 엔티티 콜렉션이 아닌 밸류 콜렉션이 더 적합하지 않은지 확인해라

5.3 M:N 연관 대체하기 : 연관 엔티티 사용

  • M:N 연관은 구현을 복잡하게 만들기 때문에 가능하면 피하는게 좋다.

  • M:N 연관을 회피하는 방법으로는 다음을 사용한다.

    • 연관 엔티티 사용
    • 한쪽 엔티티에 밸류 콜렉션으로 연관 정보 저장
  • 연관 엔티티 사용 : 조인 테이블을 엔티티로 매핑하는 것이다. M:N 연관으로 코드가 복잡해지는것보다 더 나은 선택이다. 직접적인 M:N 연관을 가졌을때와 달리 연관된 엔티티를 조회하기 위해선 JPQL을 사용해야 한다는 단점도 있다.