JPA와 데이터 타입

1. JPA에서 다루는 타입

⭐ Entity 타입

• @Entity로 정의하는 객체
• 데이터가 변해도 식별자로 지속해서 추적 가능

⭐ Value Object

• int, Integer, String처럼 값으로 사용하는 자바 기본 타입이나 객체
• 식별자가 없음. 값만 있음. 변경 시 추적 불가
• 기본 값 타입
  • 자바 기본 타입(int, double) / 래퍼 클래스(Integer, Long) / String
  • 생명 주기를 엔티티에 의존한다.
  • 값 타입은 공유하지 말아야 한다.
    • Primitive Type은 값을 공유하지 않기에 side-effect가 없다.(항상 값을 복사하기 때문)
    • Integer같은 Wrapper class나 String class는 공유 가능한 객체이지만 변경을 불가능하게 만들어 놨음.
• Embedded type : 복합 값 타입
  • 새로운 값 타입을 직접 정의할 수 있음. JPA에서는 embedded type이다. 기본 값 타입처럼 변경 불가능
  • 사용 방법
    • @Embeddable : 값 타입을 정의하는 곳에 표시
    • @Embedded : 값 타입을 사용하는 곳에 표시 
    • 단, 위의 둘 중 하나만 써도 되긴 하다.
    • 기본 생성자 필수 
    • 추가 속성
      • @AttributeOverride, @AttributeOverrides  : 속성 재정의; 한 엔티티에서 같은 값 타입을 사용할 때 사용.
  • 장점
    • 재사용이 가능. 높은 응집도, 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다.
    • 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다.
    • 해당 값 타입을 소유한 엔티티에 생명주기 의존
  • 사용하든, 안하든 매핑하는 테이블은 같다. 그렇지만 이를 사용한다면 세밀하게 매핑하는 것이 가능해진다.
  • 잘 설계한 ORM 애플리케이션은 매핑한 테이블 수보다 클래스의 수가 많다.
  • embeddedtype = null 로 저장하면, 해당 타입의 필드들도 전부 null로 저장
• collection value type: collection에 기본 값, 복합 값을 집어 넣은 타입

@Embedded
private Address homeAddress;

@Embedded
@AttributeOverrides({
        @AttributeOverride(name = "city",
        column = @Column(name = "WORK_CITY")),
        @AttributeOverride(name = "street",
                column = @Column(name = "WORK_STREET")),
        @AttributeOverride(name = "zipcode",
                column = @Column(name = "WORK_ZIPCODE"))
})
private Address workAddress;

 

 

 

2. Value Object와 불변 객체

 

질문) DTO와 VO의 차이

• DTO (Data Transfer Object) = 그냥 데이터 담은 객체 (가변성)
  • 데이터들은 DTO 객체 형태로 여러 메소드와 객체들을 여행한다.
    : 다양한 메서드를 가졌다기보다 Getter, Setter 메소드만 갖는다
• VO (Value Object) = DTO 에서 Setter 메소드를 빼면 VO (불변성)
  
  • ex) MyBatis로 DB 로부터 읽어온 SELECT 결과 객체
    객체 자체는 Java에서 사용하는 객체라 가변이다.
    하지만 변화를 주더라도 update를 따로 하지 않으면 DB의 데이터가 바뀌지 않는다는 점에서 불변 객체이다.
• Entity와는 구분해야 한다. Entity는 가변이지만, Entity를 구성하는 VO는 불변이어야 한다.

 

문제점  :  객체 타입의 한계

• 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있지만
• 문제는 Embedded type처럼 직접 정의한 값 타입은 자바의 기본 타입이 아닌, 객체 타입
  • 참조 값을 직접 대입하는 것을 막을 방법이 없다.(compile level에서)
  • 공유 참조를 피하기가 불가능
• 참고로, 자바 기본 타입은 값을 대입하면 값을 복사한다. (공유해서 쓰는 게 불가능)

 

해결 방안  :  불변 객체 사용

• 애초부터 객체 타입을 수정할 수 없게 만들어 side effect 원천 차단해야한다.
• Value Type, Value Object는 불변 객체로 설계해야 함.
  • 생성 시점 이후 절대 값을 변경할 수 없도록, setter 만들지 말고 생성자만.
• 값을 바꾸고 싶다면 어떻게 해야할까?
  • 여러 가지 방법이 있지만, 기본적인 원리는 새로운 객체를 만들어서 주입하는 방식이어야 함.
  • 새로 생성자를 통해 새 객체를 만들거나
  • 혹은 기존 VO의 값을 토대로 새로운 객체를 만드는 메서드를 정의하는 방식.

 

 

3. Value Object의 비교

인스턴스가 달라도, 그 안에 필드 값이 같으면 같은 것으로 봐야 한다.

• 동일성 비교 : 참조 값 비교 (==)
• 동등성 비교 : 인스턴스의 값 비교( equals()를 override 후 사용 )
  • 값 타입은 equals를 사용해서 동등성 비교해야 한다.
  • @EqualsAndHashCode 를 통해서 하던지 (getter를 사용하는 것이 기본 옵션이기 때문에 오히려 안전한 걸?)
  • 참고로, proxy를 사용한다면 reflection API를 통해 field 직접 접근이 아닌 getter를 통해 접근하므로
    getter 기반 메서드를 만들어야 할 수도 있으니 주의 할 것.

 

 

4. Value Object의 Collection

 

@ElementCollection
@CollectionTable(name = "FAVORITE_FOOD",
        joinColumns = @JoinColumn(name = "MEMBER_ID"))
        @Column(name = "FOOD_NAME")
private Set<String> favoriteFoods = new HashSet<>();

@ElementCollection
@CollectionTable(name = "ADDRESS",
	joinColumns = @JoinColumn(name = "MEMBER_ID"))
private List<Address> addressHistory = new ArrayList<>();

 

• 값 타입을 하나 이상 저장할 때 사용
• @ElementCollection, @CollectionTable을 사용해 별도의 테이블을 만들어야 한다.
• 값 타입 컬렉션은 본인 스스로 life cycle이 없다. ➡️ life cycle이 Member라는 Entity에 의존한다.
  • 영속성 전이 + 고아 객체 제거기능을 필수로 가진다고 볼 수 있다.
  • 값 타입 컬렉션은 default가 지연 로딩 전략 사용.
  • 수정은 java collection만 다루면 알아서 삭제 후 해결한다.
    • 다만, table에 있는 데이터를 전부 다, 완전히 갈아끼우는 방식으로 쿼리를 진행하네?
  • 언제 사용함? 너무 단순할 때.
• 제약 사항
  • Entity와 다르게 식별자 개념이 없다. (값 변경에 대한 추적이 어렵다)
  • 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 현재 값을 모두 다시 저장
• 이에 대한 대안
  • collection 대신 일대다 관계를 위한 Entity를 만들고, 값 타입을 사용.
  • 실무에서 이 방법 많이 사용한다.