[ 김영한 자바 ORM 표준 JPA 프로그래밍 - 기본편 #11 ] 실무 참고 - 설계

스프링 부트는 복잡하고 어려운 스프링 기술을 간결하고 쉽게 사용할 수 있도록 도와주는 기술이다. 그리고 JPA는 강력한 자바 ORM 표준 기술이다. 이 두 기술을 합치면 높은 개발 생산성을 유지하면서 빠르게 웹 애플리케이션을 개발할 수 있다.

 

✔️ 도메인 모델과 테이블 설계

• 관계형DB에서 FK가 있는쪽이 (일대다 관계에서) '다'가 된다. (=일대다 관계는 DB상에서 보면 항상 '다'쪽에 외래키가 있다.)
• 외래 키가 있는 곳을 연관관계의 주인으로 정해라.
  • 연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.
  • 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다.
• 참고) 다대다(N:M) 표현: 객체세상에서는 예를 들어 Category 와 Item 이 서로를 리스트로 가져버리면 다대다 관계가 표현 가능하다. 그런데 관계형 데이터베이스는 일반적인 설계로는 그게 불가능하다. 그래서 중간에 매핑 테이블(Category_item)을 둬야 한다. 중간에 매핑 테이블을 두고, 일대다, 다대일 관계로 풀어내야 한다.

 

✔️ 엔티티 설계시 주의점

• 엔티티에는 가급적 Setter를 사용하지 말자.
  • Setter 가 모두 열려있다면, 변경 포인트가 너무 많아서 유지보수가 어렵다.
  • 이론적으로 엔티티에 Getter, Setter 를 모두 제공하지 않고, 꼭 필요한 별도의 메서드를 제공하는게 가장 이상적이다. 하지만 실무에서 엔티티의 데이터는 조회할 일이 너무 많으므로, Getter 의 경우 모두 열어두는 것이 편리하다. Getter 는 아무리 호출해도 호출하는 것 만으로 어떤 일이 발생하지는 않는다. 하지만 Setter 는 문제가 다르다. Setter 를 호출하면 데이터가 변한다. Setter 를 막 열어두면 가까운 미래에 엔티티가 도대체 왜 변경됐는지 추적하기 점점 힘들어진다. 그래서 엔티티를 변경할 때는 Setter 대신에 변경 지점이 명확하도록 변경을 위한 비즈니스 메서드를 별도로 제공해야 한다.
• 모든 연관관계는 지연로딩으로 설정하자.
  • 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다.
  • 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다.
  • 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다.
  • @xxxToOne(OneToOne, ManyToOne) 관계는 기본이 즉시(EAGER)로딩이므로 직접 지연(LAZY)로딩으로 설정해야 한다.
• 컬렉션은 필드에서 초기화하자.
  • 컬렉션은 필드에서 바로 초기화하는 것이 안전하다. (null 문제에서 안전하다.)
    • ex) private List<OrderItem> orderItems = new ArrayList<>();
    • 하이버네이트는 엔티티를 영속화할 때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 임의의 메서드에서 잘못 생성하면 하이버네이트 내부 매커니즘에 문제가 발생할 수 있다. 따라서 필드레벨에서 생성하는 것이 가장 안전하고, 코드도 간결하다.
• 값 타입은 변경 불가능하게 설계해야 한다.
  • 값 타입은 기본적으로 immutable 하게 설계하는 것이 좋다. 따라서 생성할 때만 값이 세팅되고 이후에 변경하지 못하도록, 전체 값을 받는 생성자를 제공하고, @Setter 를 제공하지 말자.
    
    • @Setter 를 제거하고, 생성자에서 값을 모두 초기화해서 변경 불가능한 클래스를 만들자. JPA 스펙상 엔티티나 임베디드 타입(@Embeddable)은 자바 기본 생성자(default constructor)를 public 또는 protected 로 설정해야 한다. 그리고 public 으로 두는 것 보다는 protected 로 설정하는 것이 그나마 더 안전하다. ( JPA 가 이런 제약을 두는 이유는 JPA 구현 라이브러리가 객체를 생성할 때 리플렉션 같은 기술을 사용할 수 있도록 지원해야 하기 때문이다. )
    • 참고) 엔티티 클래스는 반드시 기본생성자를 가지고 있어야 한다. ( JPA 내부에서 엔티티를 다룰 때 기본생성자를 사용해서 리플렉션 등 처리하는 것들이 있다. )
      • 기본생성자의 접근제한자는 protected 까지는 허용해준다.

 

✔️ 참고

• EntityManager 는 @PersistenceContext 라는 표준 애노테이션이 있어야 injection(주입)된다.
  • 만약, (Spring Boot + Spring Data JPA) 를 사용하면 @Autowired 를 지원한다.
• 일반적으로 운영 yml 과 테스트 yml 은 분리하는게 좋다.
• 도메인 모델 패턴 / 트랜잭션 스크립트 패턴
  • 서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할을 하고, 엔티티가 비즈니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것을 도메인 모델 패턴이라고 한다.
  • 반대로, 엔티티에는 비즈니스 로직이 거의 없고 서비스 계층에서 대부분의 비즈니스 로직을 처리하는 것을 트랜잭션 스크립트 패턴이라 한다.
  • 두 패턴 중 실무에서 어떤 패턴이 더 좋다/맞다 는 없다. 현재 자신의 상황에 따라 유연하게 처리하는게 좋다.
• 컨트롤러에서 요청을 받거나 응답을 반환할 때, 엔티티로 처리하지 말자. ( 엔티티를 클라이언트 요청/응답에서 사용하게 되면, 엔티티 변경 시 API 스펙 자체도 변경되어 버린다. 이는 장애를 발생시킬 여지가 있다. )
  • 템플릿 엔진을 통한 아주 간단한 화면 렌더링 시 에는, 엔티티를 반환해도 무관하지만, 그러나 이 경우도 화면을 위한 별도의 필드나 기능이 필요해지고 점점 복잡해진다면, 엔티티보다는 DTO 등으로 변환해서 반환하자.
  • 단, API 를 만들때는 엔티티를 절대로 반환하지 말자. API 라는 건 스펙이다. 만약 엔티티에 필드 추가 등의 작업이 있어서 수정했다면, API 스펙도 변경된다.
    • 엔티티에 로직을 추가했는데, 그것 때문에 API 스펙이 변하는 것. -> 불안전한 API 스펙이 됨
    • 각 API 스펙에 맞는 DTO를 생성하고, 해당 DTO로 처리하는 편이 더 나은 방향이다.

---

강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 김영한 강사님께 있습니다.