자바 ORM 표준 JPA 프로그래밍 - JPA 정리하기 (9) 값 타입

JPA에서 다루는 값 타입에 대한 개념을 정리한다.

자바 ORM 표준 JPA 프로그래밍 - JPA 정리하기 (9) 값 타입

 

값 타입

---

9.1 기본값 타입

• Member -> id -> 식별자 값 // name, age 속성은 식별자 값도 없고 생명주기도 Member 엔티티에 의존함.
• 엔티티 인스턴스를 제거하면 name, age 값도 제거되므로 값 타입은 공유하면 안됨

9.2 임베디드 타입 (복합 값 타입)

• JPA에서 임베디드 타입이란 새로운 값 타입을 직접 정의해서 사용하는 것
• 직접 정의한 임베디드 타입도 int, String과 같이 값 타입이다.
• 회원 엔티티 정보에서 예를들어 근무 시작일과 우편번호는 서로 아무 관련이 없음
• 이럴때 @Embedded 을 사용하여 더욱 의미있고 응집력 있게 변경 할 수 있다.
• @Embeddable 은 값 타입을 정의하는 곳에 표시
• @Embedded 는 값 타입을 사용하는 곳에 표시

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

• 임베디드 타입은 엔티티의 값일 뿐
• 값 타입 클래스를 만들어서 더 객체지향적으로 개발 가능.

9.2.2 임베디드 타입과 연관관계

• 엔티티는 공유될 수 있으므로 참조로 표현
• 값 타입은 특정 주인에 소속되고 논리적 개념상 공유되지 않으므로 포함으로 표현

9.2.3 @AttributeOverride: 속성 재정의

• 임베디드 타입에 정의한 매핑정보를 재정의할때 사용
• @AttributeOverride를 사용하면 어노테이션을 너무 많이 사용해서 엔티티 코드가 지저분해짐

9.2.4 임베디드 타입과 null

• 임베디드 타입이 null이면 매핑한 컬럼 값은 모두 null이 된다

9.3 값 타입과 불변 객체

• 값 타입은 복잡한 객체 관계를 조금이라도 단순화하려고 만든 개념

9.3.1 값 타입 공유 참조

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다.
• 공유 참조로 인해 발생하는 버그는 찾기 어렵다.
• 값 타입을 공유해서 예상치 못한 곳에서 값이 바뀌는 경우가 발생하게되면 찾기 어렵고 이러한 부작용을 막기 위해선 값을 복사해서 사용하면 안된다.

9.3.2 값 타입 복사 

• 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
• 대신 값을 복사해서 사용해야함
• 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
• 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이라는 것
• 객체의 공유 참조는 피할 수 없는데 가장 단순한 방법은 객체의 값을 수정하지 못하게 막는 것

9.3.3 불변 객체

• 값 타입은 부작용이 일어나면 값 타입이라 할 수 없다.
• 객체를 불변하게 만들면 값을 수정할 수 없으므로 부작용을 차단할 수 있음
• 따라서 값 타입은 불변 객체로 설계해야 함
• 불변 객체의 값은 조회할 수 있지만 수정할 수 없다
• 불변 객체도 결국 객체이므로 인스턴스의 참조 값 공유를 피할 수 없다.
• 하지만 값을 수정할 수 없으므로 부작용이 발생하지 않아 괜찮음
• 불변 객체를 구현 방법은 다양하지만 가장 간단한 방법은 생성자로만 값을 설정하고 수정자를 만들지 않는 것

9.4 값 타입의 비교

• 자바 제공 객체 비교 2가지
  • 동일성 비교 : 인스턴스의 참조 값을 비교 == 사용
  • 동등성 비교 : 인스턴스의 값을 비교 equals() 사용
• 값 타입 비교 시 == 로 비교하면 둘은 서로 다른 인스턴스이므로 거짓이 나온다. 값 타입은 비록 인스턴스가 달라도 그 안에 값이 같으면 같은것으로 봐야하므로 == 가 아닌 equals()로 비교한다.
• 자바에서 equals() 재정의 시 hashCode()도 재정의하는 것이 안전하다. -> 그렇지 않으면 해시를 사용하는 컬렉션이 정상 동작 안함

9.5 값 타입 컬렉션

• 값 타입을 하나 이상 저장하려면 컬렉션에 보관하고 @ElementCollection, @CollectionTable 어노테이션을 사용
• 관계형 데이터베이스의 테이블은 컬럼안에 컬렉션을 포함할 수 없어 별도의 테이블을 추가하고 @CollectionTable을 사용해서 추가한 테이블을 매핑한다. 해당 어노테이션을 생략하면 기본값을 사용해서 매핑한다.

9.5.1 값 타입 컬렉션 사용

• 엔티티를 영속화 할때 JPA는 해당 엔티티의 값 타입도 함께 저장한다.
• 값 타입 컬렉션은 영속성 전이 + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

9.5.2 값 타입 컬렉션의 제약사항

• 엔티티는 식별자가 있으므로 엔티티의 값을 변경해도 식별자로 디비에 저장된 원본 데이터를 쉽게 찾아서 변경 가능
• 반면 값 타입은 식별자라는 개념이 없고 단순한 값들의 모임이므로 값을 변경하면 디비에 저장된 원본 데이터를 찾기 어려움
• 특정 엔티티에 소속된 값 타입은 값이 변경되어도 자신이 속한 엔티티를 디비에서 찾아 값을 변경하면 됨
• 문제는 값 타입 컬렉션인데 값 타입 컬렉션에 보관된 값 타입들은 별도의 테이블에 보관되므로 여기에 보관된 값 타입의 값이 변경되면 똑같이 원본 데이터를 찾기 어려운 문제가 발생함
• 이러한 문제로 JPA 구현체들은 값 타입 컬렉션에 변경이 발생하면 값 타입 컬렉션이 매핑된 테이블의 연관된 모든 데이터를 삭제하고 현재 값 타입 컬렉션 객체에 이쓴ㄴ 모든 값을 디비에 다시 저장
• 따라서 실무에서 값 타입 컬렉션이 매핑된 테이블에 데이터가 많다면 일대다 관계를 고려해야 함