[자바 ORM 표준 JPA 프로그래밍 - 기본편] 값 타입

인프런 - 자바 ORM 표준 JPA 프로그래밍 (김영한님) 

 

 

기본값 타입

JPA의 데이터 타입 분류

• 엔티티 타입
  • @Entity
  • 데이터가 변해도 식별자로 지속해서 추적 가능
• 값 타입
  • int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
  • 식별자가 없고 값만 있으므로 변경시 추적 불가
  • e.g) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체

 

값 타입 분류

• 기본값 타입 (변경이 불가하기 때문에 Side effect 없이 사용 가능)
  • 자바 기본 타입(int, double 등)
    • 자바 기본 타입은 절대 공유되지 않고 항상 값을 복사함
  • 래퍼 클래스(Integer, Long)
    • 클래스는 reference를 끌고 가기 때문에 공유 가능한 객체이지만 변경은 안됨
  • String
    • String은 reference를 끌고 가기 때문에 공유 가능한 객체이지만 변경은 안됨
• 임베디드 타입(embedded type, 복합 값 타입)
  • jpa에서 정해주고 사용
• 컬렉션 값 타입(collection value type)
  • jpa에서 정해주고 사용

 

 

 

임베디드 타입

• 새로운 값 타입을 직접 정의할 수 있음
• JPA는 임베디드 타입이라 함
• 주로 기본 값 타입을 모아서 만들어 복합 값 타입이라고도 함
• int, String과 같은 값 타임

 

임베디드 타입의 장점

• 재사용 가능
• 높은 응집도
• Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음
• 임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명주기를 의존함

 

 

임베디드 타입 사용법

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

 

 

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

• 임베디드 타입은 엔티티의 값일 뿐
• 임베디드 타입을 사용하기 전과 후의 매핑하는 테이블은 같다
• 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음

 

 

임베디드 타입과 연관관계

• 임베디드 타입은 임베디드 타입을 가질 수 있음
• 임베디드 타입은 엔티티도 가질 수 있음

 

 

@AttributeOverride 속성 재정의

• 한 엔티티에서 같은 값 타입을 사용하려면 ? -> 컬럼 명이 중복됨
• @AttributeOverrides, @AttributeOverride를 사용해서 컬럼명 속성을 재정의

@AttributeOverrides({
	@AttributeOverride(name="city", column=@Column(name="CITY")),
	@AttributeOverride(name="street", column=@Column(name="STREET"))
})

 

 

 

 

값 타입과 불변 객체

• 값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념
• 값 타입은 단순하고 안전하게 다뤄야 한다

 

 

값 타입 공유 참조

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함
  • 회원1과 회원2가 같은 값타입인 city를 볼 때, city 값을 NewCity로 변경하면 회원1, 회원2 모두 NewCity로 변경됨
• side effect 발생

// city, street, zipcode 임베디드 타입
Address address = new Address("city", "street", "10000");

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

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

// member1의 city만 변경했지만, member2의 city도 변경됨 -> side effect (부작용)
member1.getHomeAddress().setCity("newCity");

 

• 같이 공유해서 사용하고 싶다면, 임베디드 값 타입이 아니라 엔티티로 사용해야 함

 

 

값 타입 복사

• 값 타입의 실제 인스턴스값을 공유하는 것은 위험
• -> 값(인스턴스)를 복사해서 사용해야 함

// city, street, zipcode 임베디드 타입
Address address = new Address("city", "street", "10000");

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

// 값을 복사 
Address copyAddress = new Address(address.getCity(), address.getStreet(), addrest.getZipCode());
Member member2 = new Member();
member2.setUsername("member2");

// 복사한 Address로 set 해야 함
member2.setHomeAddress(copyAddress);
em.persist(member2);

// member1의 city만 변경됨
member1.getHomeAddress().setCity("newCity");

 

 

 

객체 타입의 한계

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

 

 

기본 타입 (primivite type)

int a = 10;
// 기본 타입은 값을 복사
int b = a; 
b = 4;

• b의 값을 4로 바꿔도 a 값은 10을 유지

 

 

 

객체 타입 (기본 타입이 아닌 모든 타입)

Address address = new Address("Old");
// 객체 타입은 참조를 전달
Address b = a;
b.setCity("New");

• b.setCity()로 값을 변경하면 a의 값도 변경됨

 

 

 

불변 객체

• 객체 타입을 수정할 수 없게 만들어야 함
• 값 타입은 불변 객체(immutable object)로 설계해야 함
  • 불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
• 생성자로만 값을 설정하고, 수정자(Setter)를 만들지 않아야 함

// city, street, zipcode 임베디드 타입
Address address = new Address("city", "street", "10000");

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

// 값을 변경하고 싶다면 생성자로만
Address copyAddress = new Address("NewCity", address.getStreet(), addrest.getZipCode());
member1.setHomeAddress(address);

 

 

 

 

값 타입의 비교

• 값 타입은 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 함
• 객체 타입은 참조 값을 비교하니까 그 안에 값이 같아도 다른 것으로 봐야 함

int a = 10;
int b = 10;

System.out.println(a == b);

// true

Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");

System.out.println(address1 == address2)

// false

 

 

값 타입의 비교

• 동일성(identity) 비교 : 인스턴스의 참조 값을 비교, == 사용
• 동등성(equivalence) 비교 : 인스턴스의 값을 비교, equals() 사용
• 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 함
  • 값 타입의 equals() 메소드를 적절하게 재정의 (주로 모든 필드 재정의)
• equals()의 기본은 == 비교여서 재정의 필요

// 재정의 하기 전
Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");

System.out.println(address1.eqauls(address2));

// false

// 재정의 후
@Override
public boolean equals(Object o) {
	if(this == o) return true;
	if(o == null || getClass() != o.getClass()) return false;
	Address address = (Address) o;
	return Objects.equals(city, address.city) &&
			Objects.equals(street, address.street) &&
			Objects.equals(zipcode, address.zipcode);
}

Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");

System.out.println(address1.eqauls(address2));

// true

 

 

 

값 타입 컬렉션

• 값 타입을 컬렉션에 담아 사용

• 값 타입을 하나 이상 저장할 때 사용
• @ElementCollection, @CollectionTable
• 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다
  • 일대다 개념이므로 컬렉션을 한 테이블에 넣을 수 없어 일대다로 풀어 별도 테이블로 만들어야 함
• 컬렉션을 저장하기 위한 **별도의 테이블**이 필요함

// Member 

public class Member {
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    @Column(name = "USERNAME")
    private String username;

    @Embedded
    private Address homdAddress;

    @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<>();
}

// Address

public class Address {
    private String city;
    private String street;
    private String zipcode;
}

일 때 자동으로 생성되는 테이블은 아래와 같음

# city, street, zipcode = homeAddress
create table Member (
       MEMBER_ID bigint not null,
        city varchar(255),
        street varchar(255),
        zipcode varchar(255),
        USERNAME varchar(255),
        primary key (MEMBER_ID)
    )
    
# MEMBER_ID = FK, (joinColumn)
create table ADDRESS (
       MEMBER_ID bigint not null,
        city varchar(255),
        street varchar(255),
        zipcode varchar(255)
    )
    
# FOOD_NAME = favoriteFoods
# MEMBER_ID = FK, (joinColumn)
create table FAVORITE_FOOD (
       MEMBER_ID bigint not null,
        FOOD_NAME varchar(255)
    )

 

 

 

값 타입 컬렉션 사용

1. 값 타입 저장 예제

Member member = new Member();
member.setUsername("member1");
member.setHomdAddress(new Address("homeCity", "street1", "zipcode1"));

member.getFavoriteFoods().add("food1");
member.getFavoriteFoods().add("food2");
member.getFavoriteFoods().add("food3");

member.getAddressHistory().add(new Address("old1", "street1", "zipcode1"));
member.getAddressHistory().add(new Address("old2", "street1", "zipcode1"));

entityManager.persist(member);

 

• 결과
• 값 타입 컬렉션을 persist하지 않아도 member만 persist해도 자동으로 저장됨(다른 테이블임에도)
  • 값 타입이기 때문에, 본인 스스로의 라이프사이클이 없어 Member의 생명주기에 소속됨
  • 값 타입 컬렉션은 영송석 전이(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있음

 

 

 

2. 값 타입 조회 예제

Member findMember = entityManager.find(Member.class, member.getId());

// Member를 조회하면 FAVORITE_FOOD, ADDRESS 테이블을 조회하지 않고 Member 테이블만 조회
// 지연로딩 개념

• 컬렉션은 지연로딩(default)

Member findMember = entityManager.find(Member.class, member.getId());

List<Address> addressHistory = findMember.getAddressHistory();
for (Address address : addressHistory) {
	System.out.println("City = " + address.getCity());
}

Set<String> favoriteFoods = findMember.getFavoriteFoods();
for (String favoriteFood : favoriteFoods) {
	System.out.println("favoriteFood = " + favoriteFood);
}

// findMember.getXXX() 로 컬렉션 값을 조회할 때만 해당 테이블을 조회함
City = old1
City = old2
favoriteFood = food1
favoriteFood = food3
favoriteFood = food2

 

 

 

3. 값 타입 수정 예제

• 값 타입은 수정이 아니라 교체!!
  • new Address()로 새로 교체해줘야 함 !

Member findMember = entityManager.find(Member.class, member.getId());

// homeCity -> newCity
// findMember.getHomdAddress().setCity("newCity"); 로 하면 안됨!! side effect 발생
Address memberAddress = findMember.getHomdAddress();
findMember.setHomdAddress(new Address("newCity", memberAddress.getStreet(), memberAddress.getZipcode()));

 

• (값 타입 컬렉션 Set) : remove 후 add

 

// food1 -> food10
findMember.getFavoriteFoods().remove("food1");
findMember.getFavoriteFoods().add("food10");
        

 

• (값 타입 컬렉션 List) : remove 후 add
  • remove 할 때 equals로 비교해서 삭제하기 때문에 equals & hashCode가 재정의 되어있어야 함

 

// Address 
public class Address {
    private String city;
    private String street;
    private String zipcode;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Address address = (Address) o;
        return Objects.equals(city, address.city) && Objects.equals(street, address.street) && Objects.equals(zipcode, address.zipcode);
    }

    @Override
    public int hashCode() {
        return Objects.hash(city, street, zipcode);
    }
}

// old1 -> old10
findMember.getAddressHistory().remove(new Address("old1", "street1", "zipcode1"));
findMember.getAddressHistory().add(new Address("old10", "street1", "zipcode1"));

// old1만 삭제되고 old10으로 insert될 줄 알았지만 
// MEMBMER_ID = 1인 모든 데이터를 삭제하고 old10, old2가 insert 됨
Hibernate: 
    /* delete collection jpa.model.Member.addressHistory */ 
delete 
        from
            ADDRESS 
        where
            MEMBER_ID=?
Hibernate: 
    /* insert collection
        row jpa.model.Member.addressHistory */ 
insert 
        into
            ADDRESS
            (MEMBER_ID, city, street, zipcode) 
        values
            (?, ?, ?, ?)
Hibernate: 
    /* insert collection
        row jpa.model.Member.addressHistory */ 
insert 
        into
            ADDRESS
            (MEMBER_ID, city, street, zipcode) 
        values
            (?, ?, ?, ?)

 

 

 

값 타입 컬렉션의 제약사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없음
  • 값을 변경하면 추적이 어려움
  • 식별자를 만드는 순간 값 타입이 아니고 엔티티가 되니까
• 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다
• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 함
  • null 입력 x, 중복 저장 x

 

 

 

값 타입 컬렉션 대안

• 실무에서는 값 타입 컬렉션 대신 일대다 관계를 고려
• 일대다 관계를 위한 엔티티를 만들고, 여기에 값 타입을 사용
• 영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션처럼 사용

// AddressEntity 생성
@Entity
@Table(name = "ADDRESS")
@Getter
@Setter
public class AddressEntity {
    @Id
    @GeneratedValue
    private Long id;

    private Address address;
}

// Member에서 일대다 관계로 매핑
public class Member {
	...
	
	@OneToMany(cascade =CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();
}

 

값 타입 컬렉션을 언제 쓰는가?

• multi-selectbox 처럼 단순하게 사용할 때
• 추적할 필요도 없고 수정할 필요도 없을 경우

 

 

 

정리

• 엔티티 타입의 특징
  • 식별자 O
  • 생명 주기 관리
  • 공유
• 값 타입의 특징
  • 식별자 X
  • 생명 주기를 엔티티에 의존
  • 공유하지 않는 것이 안전(복사해서 사용)
  • 불변 객체로 만드는 것이 안전
• 값 타입은 정말 값 타입이라 판단될 때만 사용
• 엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안됨
• 식별자가 필요하고, 지속해서 값을 추적 변경해야 한다면 값 타입이 아닌 엔티티로 사용