JPA는 데이터 타입을 최상위 레벨로 분류하면 2가지로 분류한다.
1. 엔티티 타입
- @Entity로 정의하는 객체
- 데이터가 변해도 식별자로 지속해서 추적 가능 ex) 회원의 키나 값을 변경해도 식별자로 인식 가능
2. 값 타입
- int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체
- 식별자가 없고, 값만 있으므로 변경시 추적 불가
- 예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체
값 타입은 또 세가지로 분류될 수 있다.
1. 기본값 타입
2. 임베디드 타입
3. 컬렉션 값 타입
값 타입
1. 기본값 타입
- 자바 기본 타입(int, double)
- 래퍼 클래스(Integer, Long)
- String
기본 값 타입은 String name, int age 등 기본값이다.
기본값 타입은 생명주기를 엔티티에 의존한다. 또한 값 타입은 공유하면 안된다.
ex) 회원을 삭제하면 이름, 나이 필드도 함께 삭제된다.
ex) 회원 이름 변경 시 다른 회원의 이름도 함께 변경되면 안된다.
** 참고) 자바의 기본 타입은 절대 공유되지 않는다.
public static void main(String[] args) {
int a = 10;
int b = a;
a = 20;
System.out.println("a = " + a);
System.out.println("b = " + b);
}위의 코드를 돌려봐도 결과는
a = 20
b = 10이다.
Integer같은 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 값을 변경할 수 있는 방법이 없다.
그래서 사이드 이펙트가 일어날 여지 자체가 없다.
2. 임베디드 타입(복합 값 타입)
임베디드 타입은 새로운 값 타입을 직접 정의할 수 있다.
JPA는 이것을 임베디드 타입(embedded type)이라 한다.
주로 기본 값 타입을 모아 만들어서 복합 값 타입이라고도 한다.
int, String과 같은 값 타입이다.
회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다. 잘 보면 공통 부분이 보인다. 위 회원 엔티티의 공통 부분을 정리한다면 다음과 같다.
회원 엔티티는 이름, 근무 기간, 집 주소를 가진다.
위처럼 공통된 부분을 묶어낸 것을 임베디드 타입이라 한다.
즉 클래스 두개를 뽑아낸 것이다.
임베디드 타입은 어노테이션 처리를 해서 타입을 알려줄 수 있다.
@Embeddable : 값 타입을 정의하는 곳에 표시
@Embedded : 값 타입을 사용하는 곳에 표시
기본 생성자는 필수이다.
임베디드 타입의 장점
- 재사용이 높다
- 응집도가 높아진다.
- Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메서드를 만들 수 있다.
- 임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티티에 생명주기를 의존한다.
임베디드 타입과 테이블의 매핑은 다음과 같다.
@Entity
public class Member{
@Id
@GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
@Column(name = "USERNAME")
private String name;
//Period
private LocalDateTime startDate;
private LocalDateTime endDate;
//Address
private String city;
private String street;
private String zipcode;
}코드를 작성하고 보니 date에 관련된 부분을 따로 묶고, address관련된 부분을 따로 묶는 것이 코드에 더 효율적인것 처럼 보여진다.
@Embeddable : 값 타입을 정의하는 곳에 표시
@Embedded : 값 타입을 사용하는 곳에 표시
DB의 테이블 똑같고, 객체 데이터의 매핑을 신경쓰도록 하자. 코드를 설계하면 다음과 같다.
@Embeddable
public class Period {
//기간 Period
private LocalDateTime startDate;
private LocalDateTime endDate;
public LocalDateTime getStartDate() {
return startDate;
}
public void setStartDate(LocalDateTime startDate) {
this.startDate = startDate;
}
public LocalDateTime getEndDate() {
return endDate;
}
public void setEndDate(LocalDateTime endDate) {
this.endDate = endDate;
}
}
@Embeddable
public class Address {
//주소
private String city;
private String street;
private String zipcode;
public Address(String city, String street, String zipcode) {
this.city = city;
this.street = street;
this.zipcode = zipcode;
}
public Address() {
}
public String getCity() {
return city;
}
public void setCity(String city) {
this.city = city;
}
public String getStreet() {
return street;
}
public void setStreet(String street) {
this.street = street;
}
public String getZipcode() {
return zipcode;
}
public void setZipcode(String zipcode) {
this.zipcode = zipcode;
}
}@Entity
public class Member{
@Id
@GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
@Column(name = "USERNAME")
private String name;
@Embedded
private Period period;
@Embedded
private Address homeAddress;
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Period getPeriod() {
return period;
}
public void setPeriod(Period period) {
this.period = period;
}
public Address getHomeAddress() {
return homeAddress;
}
public void setHomeAddress(Address homeAddress) {
this.homeAddress = homeAddress;
}
}
- 임베디드 타입은 엔티티의 값일 뿐이다.
- 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
- 객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다.
- 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다
임베디드 타입과 연관관계
위처럼 PhoneNumber라는 임베디드 타입이 Entity를 가질 수도 있다.
즉 임베디드 타입이 엔티티를 들고 있을수도 있다는 뜻이다.(어짜피 참조값만 가지면 되기때문에)
만약 한 엔티티에서 같은 값을 사용하면 어떻게 될까? => 컬럼명이 중복 된다.
컬럼명이 중복이 되면 @AttributeOverride라는 어노테이션을 사용해서 컬럼명 속성을 재정의해서 해결한다.
값 타입과 불변 객체
값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념이다. 따라서 값 타입은 단순하고 안전하게 다룰 수 있어야 한다.
임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 사이드 이펙트가 발생할 수 있다.
Address address = new Address("city", "street", "10000");
Member member = new Member();
member.setName("member1");
member.setHomeAddress(address);
em.persist(member);
Member member2 = new Member();
member2.setName("member1");
member2.setHomeAddress(address);
em.persist(member2);
위와 같은 코드가 있다고 가정하자, member1과 member2는 같은 주소를 참조한다.
SELECT * FROM MEMBER;
MEMBER_ID TEAM_ID ENDDATE STARTDATE USERNAME CITY STREET ZIPCODE
| 1 | null | null | null | member1 | city | street | 10000 |
| 2 | null | null | null | member1 | city | street | 10000 |
문제 없이 DB에 저장되는것을 확인할 수 있다.
근데 만약 member1이 주소를 옮기게 되며 city의 값을 변경하게 되면 어떻게 될까?
Address address = new Address("city", "street", "10000");
Member member = new Member();
member.setName("member1");
member.setHomeAddress(address);
em.persist(member);
Member member2 = new Member();
member2.setName("member1");
member2.setHomeAddress(address);
em.persist(member2);
member.getHomeAddress().setCity("newCity");
SELECT * FROM MEMBER;
MEMBER_ID TEAM_ID ENDDATE STARTDATE USERNAME CITY STREET ZIPCODE
| 1 | null | null | null | member1 | newCity | street | 10000 |
| 2 | null | null | null | member1 | newCity | street | 10000 |
member1 뿐만 아니라 member2까지 city가 newCity로 변해버렸다.
즉 임베디드 타입을 여러 엔티티에서 공유하면 위험하다. 이 문제를 어떻게 해결해야할까?
값을 복사해서 사용하는 것이 권장된다.
Address address = new Address("city", "street", "10000");
Member member = new Member();
member.setName("member1");
member.setHomeAddress(address);
em.persist(member);
Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
Member member2 = new Member();
member2.setName("member1");
member2.setHomeAddress(copyAddress);
em.persist(member2);
member.getHomeAddress().setCity("newCity");
tx.commit();SELECT * FROM MEMBER;
MEMBER_ID TEAM_ID ENDDATE STARTDATE USERNAME CITY STREET ZIPCODE
| 1 | null | null | null | member1 | newCity | street | 10000 |
| 2 | null | null | null | member1 | city | street | 10000 |
복사를 하여 사용하면 해결할 수 있다.
이런 객체타입의 한계는 다음과 같다.
- 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.
- 자바 기본 타입에 값을 대입하면 값을 복사한다.
- 객체 타입은 참조값을 직접 대입하는 것을 막을 방법이 없다.
- 객체의 공유 참조는 피할 수 없다.
기본 타입(primitive type)
int a = 10;
int b = a;//기본 타입은 값을 복사
b = 4;
객체 타입
Address a = new Address(“Old”);
Address b = a; //객체 타입은 참조를 전달
b. setCity(“New”)
--> 객체 타입을 수정할 수 없게 만들면 부작용을 원천 차단한다.
== 값 타입은 불변 객체(immutable object)로 설계해야 한다.
불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체
- 생성자로만 값을 설정하고 setter를 안만들면 된다.
참고 : Integer, String은 자바가 제공하는 대표적인 불변객체이다.
결론 : 불변이라는 작은 제약으로 큰 재앙을 막을 수 있다.
Address address = new Address("city", "street", "10000");
Member member = new Member();
member.setName("member1");
member.setHomeAddress(address);
em.persist(member);
Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());
member.setHomeAddress(newAddress);
위처럼 객체를 새로이 만들어서 집어넣어준다.
값 타입의 비교
값 타입 : 값 타입은 인스턴스가 달라도 그 안에 값이 같으면 같은 것으로 봐야 한다.
int a = 10;
int b = 10;
System.out.println("a==b: "+(a==b));위의 a==b는 당연히 true가 나온다.
아래의 값은 어떤가?
Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");
System.out.println("address1 == address2: " + (address1==address2));
어드레스의 참조값이 당연히 다르기 때문에 false가 나온다.
Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");
System.out.println("address1 == address2: " + (address1.equals(address2)));
그럼 지금 equals비교를 하면 어떻게 될까?
위 코드는 true가 나올 것 같지만 여전히 false가 나온다. equals는 기본적으로 동일성 비교를 하기 때문이다.
그렇기에 address에서 equals를 재정의하여 동등성 비교를 할 수 있도록 한다.
@Embeddable
public class Address {
//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;
}
public String getCity() {
return city;
}
public String getStreet() {
return street;
}
public String getZipcode() {
return zipcode;
}
@Override
public boolean equals(Object object) {
if (this == object) return true;
if (object == null || getClass() != object.getClass()) return false;
Address address = (Address) object;
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);
}
}
a == b: true
address1 == address2: true
이제 true가 나오는 것을 볼 수 있다.
그렇기에 값 타입 비교 시 동일성 비교와 동등성 비교를 구분해서 사용해야 한다.
- 동일성(Identity) 비교 : 인스턴스의 참조 값을 비교, == 사용
- 동등성(Equivalence) 비교 : 인스턴스의 값을 비교, equals() 사용
- 값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 한다.
- 값 타입의 equals()메소드를 적절하게 재정의 해야한다.
값 타입 컬렉션
값 타입 컬렉션은 값 타입을 컬렉션에 담아서 쓰는 것을 말 한다.
값 타입을 컬렉션으로 어떻게 넣어야 할까?
Member를 보면 favortieFoods와 addressHistory는 컬렉션으로 되어있다.하지만 기본적으로 관계형 DB는 내부적으로 테이블 안에 컬렉션을 넣을 수 있는 방법이 없다. 기본적으로는 그게 안된다.
이 문제를 해결하기 위해 FAVORITE_FOOD, ADDRESS라는 별도의 테이블을 뽑아서 매핑을 해야 한다.
독특한 점 하나를 꼽자면, 이전까지는 GenerateValue를 통해 식별자 ID를 넣어주었지만, 이 경우 식별자 ID만 PK로 잡게 되면 나머지들은 값타입이 아닌 Entity의 개념이 된다.
따라서 지금은 값타입으로 만들어주기 위해 PK로 지정한다.
FAVORITE_FOOD를 예로 들어 MEMBER_ID와 FOOD_NAME이 PK로 지정되어 있다. 따라서 동일한 속성값을 가진 튜플이 생성될 수 없다. 고유한 튜플이 생성된다.
@Entity
public class Member{
@Id
@GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
@Column(name = "USERNAME")
private String name;
@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<>();
...
}
값 타입 컬렉션
- 값 타입을 하나 이상 저장할 때 사용된다.
- @ElementCollection, @CollectionTable 어노테이션을 사용한다.
- 데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다.
- 컬렉션을 저장하기 위한 별도의 테이블이 필요하다.
그럼 저장을 어떻게 해야할까?
try {
Member member = new Member();
member.setName("userA");
member.setHomeAddress(new Address("homeCity","street","10000"));
member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");
member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));
em.persist(member);
tx.commit();
} catch (Exception e) {
tx.rollback();
e.printStackTrace();
} finally {
em.close();
}
값타입 컬렉션은 따로 persist하지 않고 member만 persist해주어도 자동적으로 DB에 인서트 쿼리 문이 나가게 된다.
즉 다른 테이블임에도 불구하고 MEMBER와 라이프 싸이클이 동일하게 돌아간다.
DB의 결과는 다음과 같다.
SELECT * FROM MEMBER;
SELECT * FROM ADDRESS;
SELECT * FROM FAVORITE_FOOD;
SELECT * FROM MEMBER;
MEMBER_ID TEAM_ID USERNAME CITY STREET ZIPCODE
| 1 | null | userA | homeCity | street | 10000 |
(1 row, 1 ms)
SELECT * FROM ADDRESS;
MEMBER_ID CITY STREET ZIPCODE
| 1 | old1 | street | 10000 |
| 1 | old2 | street | 10000 |
(2 행, 1 ms)
SELECT * FROM FAVORITE_FOOD;
MEMBER_ID FOOD_NAME
| 1 | 족발 |
| 1 | 치킨 |
| 1 | 피자 |
(3 행, 2 ms)
member를 flush하고, clear한 뒤 다시 DB에서 member를 불러와보자.
try {
Member member = new Member();
member.setName("userA");
member.setHomeAddress(new Address("homeCity","street","10000"));
member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");
member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));
em.persist(member);
em.flush();
em.clear();
System.out.println("====");
Member findMember = em.find(Member.class, member.getId());
System.out.println("====");
tx.commit();
} catch (Exception e) {
tx.rollback();
e.printStackTrace();
} finally {
em.close();
}위 코드의 결과는 다음과 같다.
====
Hibernate:
select
m1_0.MEMBER_ID,
m1_0.city,
m1_0.street,
m1_0.zipcode,
m1_0.USERNAME
from
Member m1_0
where
m1_0.MEMBER_ID=?
====
member테이블에 맞물려 돌아가는 컬렉션이 두개임에도 불구하고 member호출시 member만 Select하는 쿼리가 나갔다.
즉 값 타입 컬렉션은 지연로딩으로 이루어진다. 지연로딩인걸 확인해보자.
System.out.println("====");
Member findMember = em.find(Member.class, member.getId());
System.out.println("====");
List<Address> addressHistory = findMember.getAddressHistory();
for (Address address : addressHistory) {
System.out.println("address.getCity() = " + address.getCity());
}
System.out.println("====");
Set<String> favoriteFoods = findMember.getFavoriteFoods();
for (String favoriteFood : favoriteFoods) {
System.out.println("favoriteFood = " + favoriteFood);====
Hibernate:
select
m1_0.MEMBER_ID,
m1_0.city,
m1_0.street,
m1_0.zipcode,
m1_0.USERNAME
from
Member m1_0
where
m1_0.MEMBER_ID=?
====
Hibernate:
select
ah1_0.MEMBER_ID,
ah1_0.city,
ah1_0.street,
ah1_0.zipcode
from
ADDRESS ah1_0
where
ah1_0.MEMBER_ID=?
address.getCity() = old1
address.getCity() = old2
====
Hibernate:
select
ff1_0.MEMBER_ID,
ff1_0.FOOD_NAME
from
FAVORITE_FOOD ff1_0
where
ff1_0.MEMBER_ID=?
favoriteFood = 족발
favoriteFood = 치킨
favoriteFood = 피자
컬렉션에 입력 되었던 값을 수정하는 방법은 어떻게 될까? 컬렉션도 결국 값 타입이기 때문에 기존에 있던 값을 수정할 수 없다. 따라서 제거한 뒤 다시 생성해야 한다.
Member member = new Member();
member.setName("userA");
member.setHomeAddress(new Address("homeCity","street","10000"));
member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");
member.getAddressHistory().add(new Address("old1", "street", "10000"));
member.getAddressHistory().add(new Address("old2", "street", "10000"));
em.persist(member);
em.flush();
em.clear();
System.out.println("====");
Member findMember = em.find(Member.class, member.getId());
findMember.setHomeAddress(new Address("newCity",
findMember.getHomeAddress().getStreet(),
findMember.getHomeAddress().getZipcode()));
// findMember.getFavoriteFoods().remove("치킨");
// findMember.getFavoriteFoods().add("한식");
findMember.getAddressHistory().remove(new Address("old1", "street", "10000"));
findMember.getAddressHistory().add(new Address("newCity1", "street", "10000"));
tx.commit();
참고 : 값 타입 컬렉션은 영속성 전에(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.
값 타입 컬렉션의 제약 사항
- 값 타입은 엔티티와 다르게 식별자 개념이 없다.
- 값은 변경하면 추적이 어렵다.
- 값 타입 컬렉션에 변경 사항이 발생하면, 주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.
**중요 : 실무에서는 값 타입 컬렉션을 사용하지 않는다, 값 타입 컬렉션을 해결할 수 있는 코드를 마련하는 것이 좋다.
값 타입 컬렉션 대안
- 실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려해야 한다.
@Entity
public class AddressEntity {
@Id
@GeneratedValue
private Long id;
private Address address;
public AddressEntity() {
}
public AddressEntity(Address address) {
this.address = address;
}
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
}
엔티티를 하나 생성해서 Address를 한번 래핑하였다. 식별자가 생겼고, 안전하게 사용할 수 있게 되었다.
엔티티 타입의 특징
- 식별자 O
- 생명 주기 관리
- 공유
값 타입의 특징
- 식별자 X
- 생명주기를 엔티티에 의존
- 공유하지 않는 것이 안전
- 불변 객체로 만드는 것이 안전
'공부 > JPA' 카테고리의 다른 글
| 객체지향 쿼리 언어2 - 중급 문법 (1) | 2025.01.03 |
|---|---|
| 객체지향 쿼리 언어1 - 기본 문법 (0) | 2024.12.30 |
| 프록시와 연관관계 정리 (0) | 2024.12.21 |
| JPA 고급 매핑 (2) | 2024.12.08 |
| 다양한 연관관계 매핑 (0) | 2024.12.03 |