[JPA] 기본값 타입

동동·2022년 4월 20일

JPA

목록 보기

13/18

JPA의 데이터 타입 분류

JPA의 데이터는 분류를 했을 때 최상위로 Entity 타입과 값 타입으로 분류 가능하다.

Entity

@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속해서 추적 가능
예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능

값

변수처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
식별자가 따로 없고 값만 존재함으로 데이터가 변하면 추적 불가능
예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체
기본값 타입 / 임베디드 타입 / 컬렉션 값 타입으로 분류 가능
임베디드 타입과 컬렉션 값 타입은 JPA에서 정의를 하고 사용해야 함
값 타입은 객체를 조금이라도 단순화하려고 만든 개념
값 타입은 단순하고 안전하게 다룰 수 있어야 한다.

🚧 값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함
부작용(Side Effect) 발생

🚧 값 타입 복사

값 타입의 실제 인스턴스인 값을 공유하는 것은 위험
값을 공유하는 것 대신 값(인스턴스)를 복사해서 사용

🚧 객체 타입의 한계

항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
자바 기본 타입에 값을 대입하면 값을 복사한다.
객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.
객체의 공유 참조는 피할 수 없다.

🚧 불변 객체

객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단
값 타입은 불변 객체(immutable object)로 설계해야 함
불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨
참고
Integer, String은 자바가 제공하는 대표적인 불변객체

setter를 제거 해서 값을 변경하지 못하도록 함.
그럼 값을 수정하고 싶을 때 어떻게 하는가?
객체를 아예 새로 생성해야 함. 새로 생성한 객체로 갈아 끼워준다.

Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());
member.setHomeAddress(newAddress);

값 타입은 모두 불변 객체로 만들어야 함(변경할 수 없도록)

🚧 값 타입의 비교

값 타입 : 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 함
동일성(identity) 비교 : 인스턴스의 참조 값을 비교 (== 사용)
동등성(equivalence) 비교 : 인스턴스의 값을 비교 (equals() 사용)
값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 함
값 타입의 equals() 메소드를 적절하게 재정의(주로 모든 필드 사용) -> Hash()메소드도 함께 재정의 해줘야 함

값 타입의 분류

📌 값 타입

자바 기본 타입(int, double) / 래퍼 클래스(Integer, Long) / String
생명주기를 엔티티에 의존
예) 회원을 삭제하면 이름, 나이 필드도 함께 삭제
값 타입은 공유하면 안됨
예) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안됨(Side Effect 발생하면 안됨)
참고
- int, double 같은 기본 타입(primitive type)은 절대 공유되지 않음
- 기본 타입은 항상 값을 복사함
- Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경은 불가능(Side Effect 없음)

📌 임베디드 타입(내장타입 / Embedded Type, 복합 값 타입)

새로운 값 타입을 직접 정의할 수 있다.
주로 기본 값 타입을 모아서 만들기 때문에 복합 값 타입(Composite Value)이라고도 한다.(하이버네이트 시절에)
int, String과 같은 값 타입(Entity가 아님) -> 추적 불가
장점
- 재사용
- 높은 응집도
- Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음(객체 지향 설계 가능)
- 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에게 생명주기를 의존함

🚧 임베디드 타입 사용법

@Embeddable : 값 타입을 정의하는 곳에 표시
@Embedded : 값 타입을 사용하는 곳에 표시
기본 생성자 필수

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

임베디드 타입은 Entity의 값일뿐이다.
임베디드 타입을 사용하기 전 후 매핑되는 테이블은 같다.
객체와 테이블을 세밀하게(find-grained) 매핑하는 것이 가능하다.
잘 설계된 ORM은 매핑한 테이블의 수보다 클래스의 수가 더 많다.
잘 설계를 하면 용어와 코드가 공통화 돼서 공통으로 관리하기가 쉬움
임베디드 타입의 값이 null이면 매핑한 컬럼 값은 모두 null

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

임베디드 타입은 임베디드 타입을 가질 수 있음

🚧 한 엔티티에서 같은 임베디드 타입 사용법

한 엔티티에서 같은 임베디드 타입을 사용하면 컬럼명이 중복되게 된다.
이걸 해결하려면 ?

@AttributeOverrides, @AttributeOverride를 사용해서 컬럼명 속성을 재정의

📌 컬렉션 값 타입(Collection Value Type)

자바 컬렉션에 값 타입이나 임베디드 타입을 넣은 것
DB테이블을 구현할 때 문제
관계형 데이터 베이스는 기본적으로 컬렉션을 내부적으로 컬렉션을 넣을 수가 없다. 값만 넣을 수 있음
멤버 객체에 멤버변수로 리스트가 있으면 그 리스트를 별도의 테이블로 만들어야 한다.
컬렉션들은 일대다의 개념이기 때문에 한 테이블에 저장을 할 수가 없음

값 타입을 하나 이상 저장할 때 사용
@ElementCollection, @CollectionTable 사용
데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없음
컬렉션을 저장하기 위한 별도의 테이블이 필요함
값 타입 컬렉션도 지연 로딩 전략(fetch.LAZY) 사용
자체 라이프 사이클이 없음(따로 persist하지 않아도 부모 객체가 persist되면 함께 psersist 됨)
영속성 전이(cascade) + 고아 객체 제거(orphanRemoval) 기능을 필수로 가진다고 볼 수 있음

selectBox로 치킨, 피자 선택 등 엄청 간단한 것을 할 때만 사용

🚧 컬렉션 값 타입 수정(DELETE -> INSERT)

member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));

findMember.getAddressHistory().remove(new Address("old1", "street", "10000"));
findMember.getAddressHistory().add(new Address("newCity1", "street", "10000"));

이 코드를 실행하면 old1은 제거가 되고 newCity 객체 값만 새로 들어갈거 같지만 실제로는 insert 쿼리가 두번 실행된다.
즉, 테이블에 있는 컬렉션 값을 아예 새로 갈아치운 것

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

값 타입은 Entity와 다르게 식별자 개념이 없음
값은 변경하면 추적하기 어렵움
값 타입 컬렉션에 변경 사항이 발생하면, 주인 Entity와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장함
값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야함 -> null 입력X, 중복저장X