값 타입1

◎ JPA의 데이터 타입 분류

-> 엔티티 타입

- @Entity로 정의하는 객체

- 데이터가 변해도 식별자로 지속해서 추적 가능(회원의 나이 값을 변경해도 pk와 같은 식별자로 추적 가능)

 

-> 값 타입

- int, Integer, String 처럼 단순히 값으로 사용하는 자바 기본타입이나 객체

- 식별자가 없고 값만 있기 때문에 변경 시 추적 불가

 

◎ 값 타입 분류

-> 기본값 타입

- 자바 기본 타입(int, long, double...)

- 래퍼 클래스(Integer, Long)

- String

 

-> 임베디드 타입(embedded type, 복합 값 타입)

 

-> 컬렉션 값 타입(collection value type)

 

◎ 기본값 타입

-> 생명주기가 엔티티에 의존한다. 회원 엔티티를 삭제하면 회원의 이름, 나이 등의 필드도 함꼐 삭제된다.

-> 값 타입은 공유하면 안된다. 회원 이름이 공유되는 값이라면 A라는 회원이 이름을 변경하면 B라는 회원의 이름도 같이 변경되는데 이렇게 설계하면 안된다.

 

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

-> 새로운 값 타입을 직접 정의할 수 있다.

-> JPA는 임베디드 타입이라고 한다.

-> 주로 기본 값 타입을 모아서 만들어 복합 값 타입이라고도 한다.

-> int, String과 같은 값 타입을 가진다.

-> 다음은 임베디드 타입의 예시이다.

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

- 여기에서 근무 시작일과 근무 종료일을 근무 기간으로 묶을 수 있고, 도시, 주소 번지, 주소 우편번호를 집 주소로 묶을 수 있다.

 

- Period와 homeAddress는 임베디드 타입으로 비슷한 정보들을 하나의 객체에 담아 사용한다.

-> 값 타입을 정의하는 곳에 @Embeddable을 붙이고, 값 타입을 사용하는 곳에 @Embedded를 붙인다.

-> 기본 생성자는 필수다.

Member 엔티티

Period

Address

 

Address address = new Address("city", "street", "zipcode");

Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(address);
em.persist(member);

tx.commit();

- 위와 같이 member를 저장하고 db를 조회하면 아래와 같이 임베디드 타입들도 조회되는 것을 볼 수 있다.

 

◎ 임베디드 타입의 장점

-> 재사용성과 높은 응집도

-> Period.isWork()와 같이 해당 값 타입만 사용하는 의미있는 메서드를 만들 수 있다.

-> 임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존한다.

 

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

-> 임베디드 타입은 엔티티의 값일 뿐 임베디드 타입을 사용하기 전과 후에는 매핑하는 테이블은 같다.

-> 객체와 테이블을 세밀하게 매핑하는 것이 가능하다.

 

◎ @AttributeOverride

-> 임베디드 값 타입이 한 엔티티에서 중복이 되는 경우 @AttributeOverride를 사용해 재정의할 수 있다.

- 임베디드 값인 Address를 homeAddress와 workAddress로 중복해서 사용했다. 

- 임베디드 타입의 값이 null이면 매핑한 컬럼 값은 모두 null이다.

 

◎ 값 타입과 불변 객체

-> 임베디드 타입과 같은 값 타입을 여러 엔티티에서 공유하지 않도록 해야 한다.

try {
    // 임베디드 값 타입을 여러 엔티티에서 공유 시 문제점
    Address address = new Address("city", "street", "zipcode");

    Member member = new Member();
    member.setUsername("member1");
    member.setHomeAddress(address);
    em.persist(member);

    Member member2 = new Member();
    member2.setUsername("member2");
    member2.setHomeAddress(address);
    em.persist(member2);

    // member만 바꿨는데 member2의 city도 변경된다.
    member.getHomeAddress().setCity("newCity");

    tx.commit();

- 결과

- member와 member2가 같은 Address의 참조값을 가지고 있다. 따라서 setCity()통해 address의 city를 변경하면 해당 참조값을 가진 member와 member2가 모두 변경된다. 임베디드 타입을 사용할 때는 이 부분을 주의해야 한다.

- 실제 인스턴스 값을 공유하지 않도록 인스턴스를 복사해서 사용해야 한다.

try {
    Address address = new Address("city", "street", "zipcode");


    // 위의 방법 대신 값(인스턴스)를 복사해서 사용한다.

    Member member = new Member();
    member.setUsername("member1");
    member.setHomeAddress(address);
    em.persist(member);

    Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());

    Member member2 = new Member();
    member2.setUsername("member2");
    member2.setHomeAddress(copyAddress);
    em.persist(member2);

    // member의 city만 변경된다.
    member.getHomeAddress().setCity("newCity");

    tx.commit();

- 결과

- Address 객체를 하나 더 만들어서 member와 member2가 서로 다른 인스턴스 참조값을 가지게 하였다. 따라서 member의 city를 변경하면 member만 변경되고, member2에는 영향을 미치지 않는다.

 

◎ 값 타입의 한계

-> 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 사이드 이펙트는 해결할 수 있지만 임베디드 타입 처럼 직접 정의한 값 타입은 자바의 객체 타입이다. 객체 타입은 참조 값을 직접 대입하는 것은 막을 수 없다. 

-> 객체의 공유 참조는 피할 수 없다.

 

◎ 불변 객체

-> 객체 타입을 수정할 수 없게 만들면 사이드 이펙트를 막을 수 잆다.

-> 값 타입은 불변 객체로 설계해야 한다.

-> 생성자로만 값을 설정하고 수정자(setter)를 만들지 않아야 한다.

 

 

★ 참고

자바 ORM 표준 JPA 프로그래밍 - 기본편