값 타입

기본값 타입

JPA의 데이터 타입 분류

엔티티 타입

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

값 타입

• int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
• 식별자가 없고 값만 있으므로 변경시 추적 불가

종류

• 자바 기본 타입 (int, double)
• 래퍼 클래스 (Integer, Long)
• String

특징

• 생명주기를 엔티티에 의존 ex) 회원을 삭제하면 이름, 나이 필드도 함께 삭제
• 값 타입은 공유하면 안 됨 ex) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안 됨
• Integer 같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경되면 안 됨
  
  

임베디드 타입

• 내장 타입이라고도 하며, 주로 기본 값 타입을 모아 만들어서 복합 값 타입이라고도 함
• 새로운 값 타입을 직접 정의할 수 있음
• JPA는 임베디드 타입이라고 함
• 즉시 로딩

예시

회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다.

• 회원 엔티티는 이름, 근무 기간, 집 주소를 가진다 (추상화)
• 근무 시작일, 근무 종료일 => workPeriod
• 도시, 번지, 우편번호 => homeAddress

사용

• 어노테이션 두 가지 모두 사용하는 것을 권장한다.

@Embeddable

값 타입을 정의하는 곳에 표시

@Embedded

값 타입을 사용하는 곳에 표시

기본 생성자 필수!

장점

• 재사용
• 높은 응집도
• Period.isWork() 와 같이 해당 값 타입만 사용하는 의미 있는 메소드 생성 가능
• 용어와 코드의 공통화, 여러 도메인에서의 용어 공통화 등

임베디드 타입과 테이블 매핑

• 임베디드 타입은 엔티티의 값일 뿐인다.
• 임베디드 타입을 사용하기 전과 후에 테이블의 상태는 변화가 없다.
• 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능하다.

  	> find-grained : 더 세밀하고 작은 단위를 고려한 프로그래밍

  coarse-grained : 프로그램을 큰 덩어리로 생각한 프로그래밍

• 잘 설계한 ORM 애플리케이션은 매핑 테이블의 수보다 클래스의 수가 더 많음

임베디드 타입과 연관관계

한 엔티티에서 같은 값 타입을 사용한다면?

• 컬럼 명이 중복되어 에러 발생
  
• @AttributeOverride, @AttributeOverrides
• @AttributeOverrides({@AttributeOverride(name=, column=), ...})
  
  

값 타입과 불변 객체

• 값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이므로 단순하고 안전하게 다뤄야 한다.
• 우리는 엔티티의 값 변경에는 신경을 쓰지만 값 타입에는 신경쓰지 않는다. 자바가 설계를 잘 해놨기 때문에

값 타입 공유 참조

• 임베디드 타입 같은 값 타입은 여러 엔티팉에서 공유하면 위험함
• 값 타입의 설정된 값이 바뀌면 모든 엔티티에서 값이 바뀜. (side effect)
  - 두 회원이 공유하고 있는 oldCity
  • 한 회원에서 setCity("newCity")
  • 나머지 회원도 newCity로 바뀌며 update sql 2번 실행

값 타입 복사

• 기존의 값 타입 Address를 넣는 것이 아니라, copyAddress와 같이 값 타입을 복사하여 사용

객체 타입의 한계

• 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용 방지 가능
• 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
• 기본 타입은 값을 대입하면 값 자체를 복사하지만, 객체 타입은 참조 주소를 복사하기 때문에 객체의 공유 참조는 피할 수 없다.

불변 객체

• 객체 타입을 수정할 수 없게 만들면 부작용 차단 가능
• 값 타입은 불변 객체(immutable object)로 설계해야 함

  	> 불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체

• 생성자로만 값을 설정하고 수정자(setter)를 만들지 않거나 수정자의 접근제한자를 private으로 한다.
  
  

값 타입의 비교

동일성(identity)

• 인스턴스의 참조 값 비교
• == 사용

동등성(equivalence)

• 인스턴스의 값 비교
• equals() 사용
• 값 타입은 무조건 equals()를 사용해야 함
• equals() 메소드는 기본적으로 == 비교를 하기 때문에 적절하게 재정의해야 함 (만들어주는거 사용)
  
  

값 타입 컬렉션

• 값 타입을 하나 이상 저장할 때 사용
• @ElementCollection, @CollectionTable 사용
• DB는 컬렉션을 같은 테이블에 저장할 수 없다.
• 컬렉션을 저장하기 위한 별도의 테이블 필요
• 지연 로딩

생명주기

• 값 타입 컬렉션 또한 엔티티에 의해 생명주기가 정해진다.
• 값 타입 컬렉션은 영속성 전이, 고아 객체 제거 기능을 필수로 가진다.

값 타입 컬렉션 변경

• 컬렉션의 remove() 메소드는 equals()를 사용하므로 값 타입의 equals() 메소드를 필수로 재정의해야 삭제가 가능하다.

제약사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없다.
• 값은 변경하면 추적이 어렵다.
• 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.
• @OrderColumn : 컬렉션 순서 컬럼을 만들어서 사용하여 해결.. 할 수 있나 싶었지만 사이 순서가 비어버리면 null 값이 들어간다.
• 따라서 값 타입 컬렉션은 사용하지 말자!
• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다. (null X, 중복 X) 자세히 보면 PK를 만들 수 있는 컬럼이 없다.

대안

• 실무에서는 상황에 따라 값 타입 컬렉션 대신 일대다 관계 사용
• 35:40
• 영속성 전이, 고아 객체 제거 사용

사용

• select box에 치킨, 피자를 다중 선택하는 경우..와 같은 단순한 상황에서 사용

정리

엔티티 타입

• 식별자O
• 생명 주기 관리
• 공유

값 타입

• 식별자X
• 생명 주기를 엔티티에 의존
• 공유하지 않고 복사해서 사용하는 것이 안전
• 불변 객체로 사용

주의

• 값 타입은 정말 값 타입이라고 판단될 때만 사용 ex) 좌표
• 엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들지 말 것
• 식별자가 필요하고, 지속해서 값을 추적/변경해야 한다면 그것은 엔티티!