엔티티(Entity) 설계시 주의점

🤔 엔티티(Entity)는 Setter 사용을 지양해야 한다.

Setter가 모두 열려있다면, 변경에 편리할 수 있지만 변경 포인트가 너무 많아 유지보수가 어려워질 수 있습니다. 변경이 필요하다면 Setter를 사용하기보다 생성자를 통해 값을 채운 후, 원하는 필드를 변경하여 생성해야 합니다.

 

 

🤔 모든 연관관계는 지연로딩으로 설정한다.

즉시로딩(Eager)는 어느 부분에서 SQL이 실행될지 예측하기 어려우며, 연관관계가 매핑된 모든 엔티티를 가져오기 때문에 성능 면에서 좋지 않습니다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생하는 문제를 가집니다.

 

N+1 문제는 지연로딩도 마찬가지로 발생할 수 있으며, 이를 해결하기 위한 방법은 fetch join, 엔티티 그래프 기능 등을 사용할 수 있습니다. XxxToOne(OneToOn, ManyToOne) 관계는 기본값이 즉시로딩이기 때문에 직접 지연로딩으로 설정해야 합니다.

 

 

🤔 컬렉션은 필드에서 초기화

컬렉션은 필드에서 바로 초기화해주는 것이 안전합니다. Hibernate는 엔티티를 영속화 할 때, 컬렉션을 감싸 Hibernate가 제공하는 내장 컬렉션으로 변경됩니다. 만약 getter 메서드로 컬렉션을 호출할 때 컬렉션이 잘못 생성될 경우, Hibernate 내부 메커니즘에 문제가 발생할 수 있습니다. 따라서 필드 레벨에서 초기화를 해주는 것이 안전하며, 코드도 간결해집니다.

Member member = new Member(); // 비영속 엔티티
System.out.println(member.getOrders().getClass());

em.persist(member); // 영속 엔티티
System.out.println(member.getOrders().getClass());

class java.util.ArrayList
class org.hibernate.collection.internal.PersistentBag // Hibernate가 제공하는 내장 컬렉션으로 변경

 

 

🤔 Controller에서 REST API를 사용할 때 Entity를 직접 반환하면 안된다.

1. 스펙 변경 문제

Entity는 데이터베이스와 연관된 모델이므로 스키마 변경이나 비즈니스 로직 변경에 영향을 받습니다. 이러한 이유로 변경사항이 생길 경우 해당 Entity를 직접 반환한다면 API의 응답 형식을 모두 변경해야하는 문제를 야기합니다.

 

2. 불필요한 정보 노출

Entity는 민감한 정보가 포함될 수 있으며, 이를 외부에 노출시킬 경우 보안 문제가 발생할 수 있습니다.

 

3. 지연 로딩 문제

실무에서 Entity는 지연 로딩을 기본으로 가져가도록 설계합니다. 이때 지연 로딩을 통해 데이터를 로드할 경우 성능 문제가 발생할 수 있으며, Hibernate나 JPA에서 예외가 발생될 수 있습니다.

 

따라서 API 응답은 클라이언트의 요구에 맞게 구성되어야 하며, 요구사항에 따라 DTO를 따로 사용하여 응답하는 것이 바람직합니다.

 

 

🤔 연관관계를 단방향으로 먼저 설계해야 한다.

1. 간단성과 유연성

단방향 관계는 설계를 간단하게 만들어줍니다. 양방향 관계는 두 Entity 사이의 상호 의존성을 도입하며, 이는 복잡성을 증가시킵니다. 따라서 최초 설계는 단방향으로 시작하여, 필요에 따라 양방향 관계를 맺는 것이 좋습니다.

 

2. 순환 참조 문제 방지

예를 들어 양방향 관계는 한 엔티티 A가 엔티티 B를 참조하고, 동시에 엔티티 B가 다시 엔티티 A를 참조할 수 있습니다. 이러한 경우 무한 루프가 발생될 수 있습니다. 단방향 관계는 이러한 순환 참조 문제를 방지할 수 있습니다.

 

 3. 데이터 일관성 유지

양방향 관계는 두 엔티티 사이에 일관성을 유지하기 위해 더 많은 관리 작업이 필요합니다. 그러나 단방향 관계는 두 엔티티를 모두 신경쓰지 않아도 데이터의 일관성을 유지할 수 있습니다.