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

JPA 데이터 타입 분류

엔티티 타입

• @Entity 로 정의하는 객체

• 식별자가 존재하므로 데이터가 변해도 식별자로 지속해서 추적이 가능하다.

• 생명 주기를 제어할 수 있다.

• 공유할 수 있다.

• 예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 각각의 개체로 인식 가능하다.

 

값 타입

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

• 식별자가 없고 값만 있으므로 변경 시 추적이 불가능하다.
  • 예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체된다.

• 값 타입은 소유한 엔티티에 생명 주기를 의존한다. 생명 주기를 제어할 수 없다.

• 공유하지 않는 것이 안전하다. 만약, 공유해야 하는 경우에는 불변 객체로 만들어 사용해야 한다.
  • 새로 생성해서 사용해야 한다.

• 값 타입 분류
  • 기본 값 타입
    • 자바 기본 타입(Primitive type)
      • 예) int, double, ...
    • 래퍼 클래스
      • 예) Integer, Long, ...
    • String
  • 임베디드 타입(embedded type, 복합 값 타입)
  • 컬렉션 값 타입(collection value type)

 

값 타입은 값 타입이라 판단될 때만 사용해야 한다.
식별자가 필요하고 지속해서 값을 추적하고 변경해야 한다면 값 타입이 아니라 엔티티이다.

 

기본 값 타입

• 생명주기를 엔티티에 의존한다.
  • 예) 회원을 삭제하면 이름, 나이 필드도 함께 삭제된다.

• 값 타입은 공유하면 안된다.
  • 예) 값 타입을 공유한다면 회원 이름 변경 시, 다름 회원의 이름도 함께 변경되는 문제가 발생한다.

• 자바 기본 타입은 절대로 공유되지 않는다.
  • 기본 타입(Primitive type)은 항상 값을 복사한다.
  • 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경이 불가능하다.(Immutable)
    • 예) 래퍼 클래스나 String 클래스에서는 값을 변경하는 기능을 제공하지 않는다.
    • 박싱을 이용해서 값을 변경한다고 해도 새로운 래퍼 클래스나 String 클래스가 생성되어 기존 참조가 새로 생성된 클래스를 가리키도록 수정되는 것이지 기존에 참조하고 있던 클래스의 값이 변경되는 것은 아니다.

 

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

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

• 기본 값 타입을 모아서 만들기 때문에 복합 값 타입이라고도 한다.
  • 예) 생년월일 = 년도 + 월 + 일
  • 예) 기간 = 시간일 + 종료일

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

• 임베디드 타입은 엔티티 타입이 아니라 엔티티의 값이다.

• 임베디드 타입 사용 시, 기본 생성자가 필수로 있어야 한다.

• 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
  • 데이터베이스 입장에서는 바뀌는 것이 없다. 임베디드 타입에 해당하는 컬럼을 매핑시켜주면 된다.
  • 예)

 

@Embeddable

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

• JPA에게 해당 클래스가 값 타입임을 알려주는 역할을 한다.

 

@Embedded

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

 

@AttributeOverrides, @AttributeOverride

• 한 엔티티에서 같은 값 타입을 여러 개 사용할 때 컬럼명이 중복되는 경우가 발생한다.

• 이러한 경우 위의 애노테이션을 사용해서 같은 값 타입을 별도의 컬럼에 저장시킬 수 있다. 

@Entity
@Getter @Setter
public class Member {
    @Id
    @GeneratedValue
    private Long id;

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

    @ManyToOne(fetch = FetchType.LAZY)//Member 입장에서는 다에 해당하기 떄문에 Many 팀은 1
    @JoinColumn(name = "TEAM_ID") //조인해야하는 컬럼명
    private Team team;

    @Embedded
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
            @AttributeOverride(name="city",
                    column=@Column(name = "WORK_CITY")),
            @AttributeOverride(name="street",
                    column=@Column(name = "WORK_STREET")),
            @AttributeOverride(name="zipcode",
                    column=@Column(name = "WORK_ZIPCODE"))
    })
    private Address workAddress;
}

 

임베디드 타입과 연관관계

• 임베디드 타입 내부에 엔티티를 가지는 것도 가능하다.

 

임베디드 타입의 장점

• 재사용이 가능하다.

• 높은 응집도를 가진다.

• 객체와 테이블을 세밀하게 매핑하는 것이 가능하다.
  • 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있다.
  • 수 많은 컬럼들을 추상화 했기 때문에 도메인이 공유된 상태라면 쉽게 설명하고 이해할 수 있다.

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

 

 

값 타입과 불변 객체

값 타입 공유 참조

• 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다. 부작용(side effect) 발생
  • 동일한 주소 인스턴스를 참조하는 회원이 여러 명일 경우, 회원1의 주소를 얻어와서 수정하는 것도 다른 회원(회원2)에게 영향을 준다.
  • 회원1의 주소 데이터만 수정되는 것이아니라 회원2 주소 데이터도 같이 수정된다.

값 타입 복사

• 값 타입의 실제 인스턴스인 값을 공유하는 것은 부작용(side effect)이 발생하므로 위험하다.

• 따라서 인스턴스 참조값을 공유하는 것이 아니라 해당 인스턴스를 그대로 복사해서 사용하는 것이 안전한 방법이다.

 

객체 타입의 한계

• 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수는 있다.

• 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
  • 자바 기본 타입은 값을 항상 복사해서 사용하지만 객체 타입은 참조를 대입해서 사용한다.

• 객체 타입 참조 값을 직접 대입하는 것을 막을 방법이 없다.
  • 컴파일 상황에서 오류 발생이 불가능 하다.
  • 객체의 공유 참조는 피할 수 없다.

• 예) 기본 타입에서 a의 결과는 10, b는 4. 객체 타입에서는 a, b의 City결과는 New 이다.

 

불변 객체

• 불변 객체란 생성 시점 이후 절대 값을 변경할 수 없는 객체를 의미한다.

• 객체 타입을 수정할 수 없게 만들면 부작용이 원천 차단된다.

• 값 타입은 불변 객체(Immutable Object)로 설계해야 한다.

• 불변 객체 만드는 방법
  • 생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 된다.
    • 내부에서만 사용하려면 수정자를 private로 만들면된다.
  • 예) Integer, String 클래스는 자바가 제공하는 대표적인 불변 객체

• 불변 객체의 값을 바꾸고 싶다면 새로운 객체를 만들어서 해당 객체로 대체해야 한다.

 

값 타입의 비교

• 동일성(identity) 비교
  • 인스턴스의 참조 값을 비교. == 사용

• 동등성(equivalence) 비교
  • 인스턴스의 값을 비교, equals() 사용

• 값 타입은 인스턴스 주소가 달라도 그 안에 들어있는 값이 같다면 동일한 것으로 판단 해야한다. 따라서 값 타입은 동등성 비교를 해야한다.

• 이를 위해서 값 타입의 equals() 메소드를 적절하게 재정의 해야 한다.
  • 주로 모든 필드를 재정의해서 사용한다.
  • 컬렉션을 다룰 때, 보통 equals() 를 이용해서 객체의 동등성을 비교한다.
  • Use getters during code generation를 체크해서 equals()를 재정의하는 것이 좋다.
    • 체크하지 않으면 필드에 직접 접근해서 재정의된다. 필드에 직접 접근해서 하는 방식의 문제점은 프록시로 동작할 경우에는 필드에 접근이 불가능하여 equals() 계산이 안된다.
    • equals(), hashCode()가 아닌 경우라도 대부분의 코드는 프록시를 고려하여 필드에 직접 접근하는 것보다는 메서드를 이용해서 값을 호출하도록 구현하는 것이 안전하다.

• equals()를 재정의할 때는 hashCode()도 같이 재정의 해야한다.
  • hash 값을 사용하는 컬렉션에서 문제를 일으키지 않기 위해서이다.
    • HashSet, HashMap 등등
  • hash 값을 사용하는 컬렉션은 객체가 논리적으로 같은지 비교할 때 아래 과정을 거친다.
    1. hashCode() 의 값이 같은지 비교. 다르다면 다른 객체
    2. equals()의 값이 같은지 비교. 다르다면 다른 객체
    3. hashCode() 와 equals() 값이 모두 같으면 동등한 객체로 인식한다.

 

값 타입 컬렉션

• 값 타입을 컬렉션에 담아서 쓰는 것을 말한다.

• 매우 단순할 때 사용해야 한다. 복잡한 경우는 대부분 엔티티에 해당된다.
  • 예) 음식 목록이 존재할 때, 체크박스로 치킨, 피자와 같이 음식을 여러 개 선택하는 경우
  • 값을 추적할 필요가 없고 업데이트할 필요도 없을 때

 

@ElementCollection, @CollectionTable

• 값 타입을 하나 이상 저장할 때 사용한다.

• 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다. 따라서 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.

• @ElementCollection는 값 타입 컬렉션이라는 것을 알려주고 @CollectionTable는 컬렉션을 저장하기 위한 별도의 테이블을 지정한다.

• 값 타입 컬렉션은 생명주기를 엔티티에 의존한다.
  • 엔티티의 값 타입 컬렉션이 변경된 경우 수정 SQL이 발생되고 엔티티의 값 타입 컬렉션에 추가된 경우 등록 SQL이 발생한다.
  • 이는 값 타입 컬렉션이 영속성 전이(Cascade)와 고아 객체 제거 기능을 함께 가지고 있다고 볼 수 있다.

• 값 타입 컬렉션(@ElementCollection)은 기본으로 지연 로딩 전략(LAZY)을 사용한다. 따라서 필요한 시점에 쿼리가 발생한다.

• 예)

@Entity
@Getter @Setter
public class Member {
    @Id
    @GeneratedValue
    private Long id;

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;

    @Embedded
    private Address homeAddress;

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

}

@Embeddable
public class Address {
    private String city;
    private String street;
    private String zipcode;

    public Address () {

    }

    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = 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);
    }
}

public class JpaMain2 {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        try {

            Member member = new Member();
            member.setName("member1");
            member.setHomeAddress(new Address("homeCity", "street", "100000"));

            member.getFavoriteFoods().add("치킨");
            member.getFavoriteFoods().add("떡볶이");
            member.getFavoriteFoods().add("피자");

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

            em.persist(member);

            em.flush();
            em.clear();
            System.out.println("======================");
            Member findMember = em.find(Member.class, member.getId());
            Address homeAddress = findMember.getHomeAddress();
            //homeCity 에서 newCity 로 주소가 변경되는 상황
            //findMember.getHomeAddress().setCity("newCity"); 사이드 이펙트가 발생할 수 있기 때문에 이 방법으로 변경해서는 안된다.
            findMember.setHomeAddress(new Address("newCity", homeAddress.getStreet(), homeAddress.getZipcode())); // 불변 객체를 이용하여 참조 자체를 수정

            //컬렉션 값 타입을 변경. 피자 -> 족발
            findMember.getFavoriteFoods().remove("피자");
            findMember.getFavoriteFoods().add("족발");
            
            //컬렉션 값 타입을 변경. old1 -> new1
            findMember.getAddressHistory().remove(new Address("old1", "street", "100000")); // 컬렉션은 대상을 찾을 때 일반적으로 equals()를 사용한다.
            findMember.getAddressHistory().add(new Address("new1", "street", "100000")); // 컬렉션은 대상을 찾을 때 일반적으로 equals()를 사용한다.


            tx.commit();
        } catch (Exception e) {
            tx.rollback();
            e.printStackTrace();
        } finally {
            em.close();
        }
        emf.close();
    }
}

 

값 타입 컬렉션의 제약사항

• 값 타입은 엔티티와 다르게 식별자 개념이 없다.

• 값은 변경하면 추적이 어렵다.

• 값 타입 컬렉션에 변경사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.

• 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본 키를 구성해야 한다.
  • null 입력할 수 없고 중복 저장을 하면 안된다.

 

값 타입 컬렉션 대안

• 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다(1:N) 관계 사용을 고려해야 한다.
  • 일대다(1:N) 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용한다.

• 영속성 전이(Cascade)와 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용할 수 있다.

• 예)

  @Entity
  @Getter @Setter
  @Table(name = "ADDRESS")
  public class AddressEntity {
  
      @Id
      @GeneratedValue
      private Long id;
  
      private Address address;
  
      public AddressEntity() {
      }
  
      public AddressEntity(String city, String street, String zipcode) {
          this.address = new Address(city, street, zipcode);
      }
  }
  
  @Entity
  @Getter @Setter
  public class Member {
      @Id
      @GeneratedValue
      private Long id;
  
      @Column(name = "USERNAME")
      private String name;
  
      @Embedded
      private Address homeAddress;
  
  		...
  
  //  @ElementCollection
  //  @CollectionTable(name = "ADDRESS", joinColumns =
  //      @JoinColumn(name = "MEMBER_ID")
  //  )
  //  private List<Address> addressHistory = new ArrayList<>();
  
  //  값 타입을 엔티티로 승격
      @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
      @JoinColumn(name = "MEMBER_ID")
      private List<AddressEntity> addressHistory = new ArrayList<>();
  
  
  }
  public class JpaMain2 {
      public static void main(String[] args) {
          ...
          tx.begin();
  
          try {
  
              Member member = new Member();
              member.setName("member1");
  
              ...
  
              member.getAddressHistory().add(new AddressEntity("old1", "street", "100000"));
              member.getAddressHistory().add(new AddressEntity("old2", "street", "100000"));
  
              em.persist(member);
  
  	          ...
  
              tx.commit();
          } catch (Exception e) {
              tx.rollback();
              e.printStackTrace();
          } finally {
              em.close();
          }
          emf.close();
      }
  }

---

[참고자료]

자바 ORM 표준 JPA 프로그래밍 - 기본편, 김영한