Entity 클래스 개발

  • 실무에서는 가급적 getter는 열고 setter는 꼭 필요한 경우에만 사용하자.

    • 데이터를 조회할 일이 많으므로 getter는 모두 열어두는 게 편하다.

    • 하지만 setter는 호출하면 데이터가 변하므로 막 열어두면 Entity가 도대체 왜 변경되는지 추적하기가 힘들다.

    • 따라서 Entity를 변경할 때는 setter 대신 변경만을 위한 비즈니스 메서드를 따로 제공해야 한다.

회원 Entity

@Entity
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id")
    private Long id;
    private String name;

    // 내장 타입을 사용할 때 붙인다.
    // Embedded, Embeddable 둘 중 하나만 있으면 되지만 명시적으로 둘 다 적는다.
    @Embedded
    private Address address;

    // mappedBy로 매핑되는 읽기 전용이라고 명시한다.
    @OneToMany(mappedBy = "member")
    private List<Order> orders = new ArrayList<>();
}
  • Entity 식별자는 id를 사용하고 PK 칼럼은 member_id를 사용했다.

    • Entity는 Member라는 타입이 있으니까 id라는 이름만으로도 구별이 가능하다.

    • 테이블은 타입이 없어 어떤 데이터의 id인지 구별이 힘들다.

  • 관례상 테이블명 + id를 많이 사용한다.

  • 객체에서도 id 대신 memberId를 써도 된다. 중요한 건 일관성이다.

주문 Entity

  • 객체는 가지고 있는 Entity 둘 다 데이터를 변경해야 한다.

  • DB는 FK로 한 번만 변경해주면 된다.

  • 따라서 FK가 있는 곳을 연관 관계의 주인으로 정한다.

    • 해당 FK로 관련된 값을 함께 변경한다는 의미다.

  • Order가 연관 관계의 주인이다.

    • Order 테이블에 MEMBER_ID라는 FK가 있다.

주문 상품 Entity

하나의 주문 아이디에 여러 주문 상품이 들어가므로 FK로 order_iditem_id를 갖는다.

상품 Entity

상속 관계로 정의한다.

배송 Entity

  • 배송과 주문은 일대일 매핑이다.

  • 일대일은 FK를 어디다 둘지 선택할 수 있다.

    • 주로 접근하는 데이터에 두면 좋다.

    • 주문을 보면서 배송을 보는 일이 많으므로 주문에 delivery_id를 FK로 둔다.

    • 연관 관계 주인은 Order.delivery가 된다.

카테고리 Entity

주소 Entity

  • 값 타입은 기본적으로 immutable하게 즉, 변경이 되지 않아야 한다.

  • 그래서 setter를 사용하지 않고 무조건 새로 생성해서 쓰도록 생성자를 사용한다.

  • 생성자를 만들 때 기본 생성자도 함께 만들어야 한다.

    • JPA가 생성 시에 리플렉션이나 프록시 같은 기술을 써야하는데 기본 생성자가 없으면 사용할 수가 없다.

    • JPA 스펙 상 Entity나 임베디드 타입은 기본 생성자를 public이나 protected로 설정해야 한다.

      • public보다는 안전하게 protected로 해주자.

Last updated

Was this helpful?