Home JPA - 프록시와 연관관계 관리(2)
Post
Cancel

JPA - 프록시와 연관관계 관리(2)

By ISSuh
Posted 2023-10-25 Updated 2024-04-23 13 min read

JPA의 데이터 타입

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

값 타입 분류

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

기본값 타입

  • 생명주기를 엔티티의 의존
    • 예) 회원을 삭제하면 이름, 나이 필드도 함꼐 삭제
  • 값 타입은 공유하면 안됨
    • 예) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안됨

자바의 기본 타입은 공유 X int, double 같은 기본 타입은 공유되지 않고 항상 값을 복사함. Integer 같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능할 객체이지만 변경 X

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

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

Alt text


값 타입 사용법 으로는 아래와 같음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

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

  public Address() {
  }

  ...
}

@Entity
public class Member {
  ...

  @Embedded
  private Address address;

  ...
}
  • @Embeddable : 값 타입을 정의하는 곳에 표시
    • 기본 생성자 필수
  • @Embedded : 값 타입을 사용하는 곳에 표시(생략 가능)

입베디드 타입의 장점

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

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

Alt text

  • 테이블은 변하는것 없이 그대로이며 엔티티내의 객체만 나누어 진 것
  • 임베디드 타입은 엔티티의 값일 뿐 임
  • 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같음
  • 객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능
  • 임베디드 타입의 값이 null이면 매핑한 컬럼 값은 모두 null

Alt text

속성 재정의 하나의 엔티티에서 같은 값 타입을 사용할떄, 컬럼명이 중복되어 에러 발생. 이를 해결하기 위해 @AttributeOverrides, @AttributeOverride 를 사용하여 컬럼명 속성을 재정의 하여 사용해야 함.

값 타입과 불변 객체

값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이므로 값 타입은 단순하고 안전하게 다룰 수 있어야 함

값 타입 사용시 주의

1
2
3
4
5
6
7
8
9
10

Address addr = new Address(“OldCity”);

Memmber member1 = new Member();
Memmber member2 = new Member();

member1.setAddress(addr);
member2.setAddress(addr);

Address memberAddress = member1.getAddress();
memberAddress.setCity("NewCity");

Alt text

  • 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 부작용이 발생 할 수 있음
  • 두개의 엔티티가 서로 같은 값 타입 인스턴스를 공유하므로 한쪽에서 값을 수정하면 다른 한쪽에서도 같이 수정됨


이에 대한 대안으로 값을 공유하는 것이 아닌 복사해서 사용하도록 함

1
2
3
4
5
6
7
8
9

Address addr1 = new Address(“OldCity”);

Memmber member1 = new Member();
Memmber member2 = new Member();

member1.setAddress(addr);

Address addr2 = new Address(addr1.getCity());
member2.setAddress(addr2);

Alt text

객체 타입의 한계

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

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

1
2
3

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

불변 객체

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

값 타입의 비교

값 타입은 인스턴스가 달라도 그 안의 값이 같으면 같은 것으로 봐야 함

1
2

int a = 10;
int b = 10;

1
2

Address a = new Address("a");
Address b = new Address("a");

그러므로 값 타입을 비교할떄 동일성 비교 보단 동등성 비교로 값타입을 비교 해야함

  • 동일성(identity) 비교
    • 인스턴스의 참조 값을 비교
    • == 사용
  • 동등성(equivalencee) 비교
    • 인스턴스의 값을 비교
    • equals() 사용
    • 값 타입은 a.equals(b) 와 같이 동등성 비교를 해야함
    • 값 타입의 equals() 메소드를 적절하게 재정의 하여 비교에 사용해야 함

값 타입 컬렉션

  • 값 타입을 하나 이상 저장할떄 사용
  • @ElementCollection, @CollectionTable 사용
  • 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없으므로 컬렉션을 저장하기 위한 별도의 테이블이 필요

Alt text

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class Member {
  ...

  @ElementCollection
  @CollectionTable(
    name = "FAVORITE_FOOG",
    joinColumm = @JoinColumm(name = "FOOD_NAME")
  )
  private Set<String> favoriteFoods = new HashSet<>();

  @ElementCollection
  @CollectionTable(
    name = "ADDRESS",
    joinColumm = @JoinColumm(name = "MEMBER_ID")
  )
  private List<Address> addressHistoty = new ArrayList<>();

  ...
}
  • 매핑된 값타입의 라이프사이클은 소유한 엔티티가 관리하게 됨


이러한 값 타입 컬렉션을 사용할 떄 저장, 조회의 경우는 단순히 엔티티와 비슷하게 사용하면 되지만, 수정의 경우 주의할 점이 있음

1
2
3
4
5

Member findMember = em.find(Member.class, id);

// 치킨 -> 한식
findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().remove("한식");
  • 값 타입 컬렉션도 지연 로딩 전략 사용
  • 값타입의 수정은 단순히 setter로 값 타입 내의 필드값을 수정하는게 아닌 값 타입을 새로 생성하여 인스턴스를 교체해야 함
  • 값 타입 컬렉션의 경우 업데이트 하고 싶은 엘리먼트를 지우고 새로운 값을 엘리먼트로 넣어주어야 함
  • 단, 값 타입 컬렉션의 엘리먼트를 지울떄, 주인 엔티티와 연관된 모든 데이터를 삭제하고 다시 갱신하기 떄문에 delete 쿼리가 여러개 수행됨

값 타입 컬렉션 제약사항

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

값 타입 컬렉션 대안

  • 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려
  • 일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용
  • 영속석 전이(Cascade) + 고아 객체 제거를 사용하여 값 타입 컬렉션 처럼 사용
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Entity
@Table(name = "ADDRESS")
public class AddressEntity {
  ...

  private Address address;

  ...
}

@Entity
public class Member {
  ...

  @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
  @JoinColumm(name = "MEMBER_ID")
  private List<Address> addressHistoty = new ArrayList<>();

  ...
}

값 타입 정리

  • 엔티티 타입 특징
    • 식별자가 존재함
    • 생명 주기 관리
    • 공유
  • 값 타입 특징
    • 식별자가 존재하지 않음
    • 생명 주기를 엔티티에 의존
    • 공유하지 않는 것이 안전(복사해서 사용해야 함)
    • 불변객체로 만드는 것이 안전

값 타입은 정말 값 타입이라 판단될 떄만 사용. 엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안됨. 식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 그것은 값 타입이 아닌 엔티티.

참고

  • 자바 ORM 표준 JPA 프로그래밍(김영한)
Backend, JPA
Web Spring Framework DataBase JPA
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents