본 문서는 인프런의 자바 ORM 표준 JPA 프로그래밍 - 기본편 (김영한) 강의를 공부하며 작성한 개인 노트입니다.
🚣🏾♂️ 기본값 타입
엔티티 타입
@Entity- 데이터가 변해도 식별자로 지속해서 추적 가능
(예) 회원 엔티티의 키/나이 값을 변경해도 식별자로 인식 가능
값 타입
- int, Integer, String
- 단순값으로 사용하는 자바 기본타입/객체
- 식별자 X. 값만 있음 > 변경시 추적 X
(예) 숫자 100 > 200 변경시 완전히 다른 값이 됨
값 타입 분류
- 기본값 타입
- 자바 기본 타입: int, double, etc.
- (예) String name, int age
- 래퍼 클래스, wrapper class: Integer, Long, etc.
- String
- 생명주기는 엔티티에 의존 (예) 회원을 삭제하면 이름/나이 필드도 함께 삭제
- 값 타입은 공유 X (예) 회원 이름 변경시 다른 회원의 이름은 변경되면 안됨
- Wrapper & String 클래스는 공유 가능한 객체지만 변경은 안됨
- 자바 기본 타입: int, double, etc.
- 임베디드 타입, embedded type: 복합 값 타입
- 좌표같이 묶어서 값을 쓰고 싶을 때
- 컬렉션 타입, collection value type
🎟️ 임베디드 타입 (복합값 타입)
- 임베디드 타입, 내장 타입, 복합값 타입
- 새로운 값 타입을 직접 정의
- JPA는 임베디드 타입이라 함
- int, String과 같은 값 타입
예제) 회원 엔티티는 이름, 근무 시작일, 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다
-> 회원 엔티티는 이름, 근무 기간, 집 주소를 가진다
사용법
@Embeddable- 값 타입을 정의하는 곳에 표시@Embedded- 값 타입을 사용하는 곳에 표시- 기본생성자 필수
Address.class
@Embeddable
public class Address {
private String city;
private String street;
private String zipcode;
}Member.class
@Entity
public class Member {
...
@Embedded
private Address homeAddress;
}장점
- 재사용
- 높은 응집도
- 해당 값 타입만 사용하는 의미 있는 메소드 생성 가능
- 임베디트 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기 의존
임베디드 타입과 테이블 매핑
- 임베디드 타입은 엔티티의 값일 뿐
- 임베디드 타입을 사용하기 전 & 후에 매핑하는 테이블은 같음
- 객체와 테이블을 아주 세밀하게 (fine-grained) 매핑 가능
- fine-grained: 특정 프로세스/서비스를 잘게 쪼개기
- 잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음
@AttributeOverride
@AttributeOverride - 속성 재정의
- 한 엔티티에서 같은 값 타입을 사용 > 컬럼명 중복
- 본 어노테이션으로 컬럼명 속성 재정의
@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"))
})임베디드 타입과 null
임베디드 타입이 null이면 매핑한 컬럼값은 모두 Null
값 타입과 불변 객체
값 타입은 단순/안전하게 다뤄야함
값 타입 공유 참조
임베디드 타입과 같은 값 타입을 여러 엔티티에서 공유하면 위험함
- 부작용 발생
- 두객체가 같은 주소를 참조하면 한 객체의 주소를 바꾸기 위해 주소 변경했다가 두 객체 모두의 주소가 변경됨
- 고의로 공유하고 싶으면 엔티티로 만들어야함
- 공유하고 싶지 않으면 값을 복사해서 사용
Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());객체 타입의 한계
- 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있음
- 하지만 임베디드 타입처럼 직접 정의한 값 타입은 객체 타입이다 (자바의 기본 타입 X)
- 자바 기본 타입에 값을 대입하면 값을 복사함
- 객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없음
- 객체의 공유 참조는 피할 수 없음
불변 객체
- 객체 타입을 수정할 수 없게 만들어서 부작용 원천 차단
- 값타입은 불변객체 (immutable object)로 설계
- 불변객체: 생성 시점 이후 절대 값을 변경할 수 없는 객체
- 생성자로만 값을 설정 & setter 생성 X
- 불변 객체 예시: Integer, String, etc.
값 타입의 비교
값 타입 - 인스턴스가 달라도 그 안에 값이 같으면 같은것으로 침
값타입의 비교
- 동일성(identity) 비교: 인스턴스의 참조값 비교
==사용
- 동등성(equivalence) 비교: 인스턴스 값 비교
equals()사용equals()의 기본은==비교
- 값타입 비교에 적절 > 필요에 따라 재정의
@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);
}equals()를 구현할 거면 hashCode()도 구현해야함
@Override
public int hashCode() {
return Objects.hash(city, street, zipcode);
}값 타입 컬렉션
- 값 타입을 컬렉션에 넣어 사용
- 값 타입을 하나 이상 저장할 때
@ElementCollection,@collectionTable사용- 디비는 컬렉션을 같은 테이블에 저장할 수 없다
- 컬렉션을 저장하기 위한 별도의 테이블 필요
@ElementCollection
@CollectionTable(name = "FAVORITE_FOOD", joinColumns =
@JoinColumn(name = "MEMBER_ID")
private Set<String> favoriteFoods = new HashSet<>();값 타입 컬렉션 사용
값 타입 저장
- member만 persist하면 collection(다른 테이블임에도 불구하고)도 같이 persist됨
- 컬렉션도 member에 생명주기를 의존함
- 컬렉션은 별도 persist 필요 없음
try {
Member member = new Member();
member.setUsername("member1");
member.setHomeAddress(new Address("homeCity", "street", "2941");
member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getAddressHistory().add(new Address("old1", "street", "192391");
em.persist();
tx.commit();
}값 타입 조회 (지연로딩)
try {
...
Member findMember = em.find(Member.class, member.getId());
tx.commit();
}값 타입 수정
try {
...
// homeCity -> newCity
Address a = findMember.getHomeAddress();
findMember.setHomeAddress(new Address("newCity", a.getStreet(), a.getZipcode());
// 치킨 -> 한식
findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().add("한식");값 타입 제거
try {
findMember.getAddressHistory().remove(new Address("old1", "street", "10000"));
findMember.getAddressHistory().add(new Address("newCity1", "street", "10000"));
}- 위를 실행하면 결로적으로는 원하는대로 진행됨
- ADDRESS에 MEMBER_ID 값이 같은 것은 모두 삭제한 후 나머지는 다시 insert
값 타입 컬렉션의 제약사항
- 값 타입은 엔티티와 다르게 식별자 개념이 없음
- 값은 변경하면 추적이 어려움
- 값 타입 컬렉션에 변경사항이 발생하면 주인 엔티티와 연관된 모든 데이터를 삭제하고 값 타입 컬렉션에 있는 현재값을 모두 다시 저장함
- 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 함
- null 입력 X & 중복 저장 X
값 타입 컬렉션 대안
- 값 타입 컬렉션 대신에 일대다 관계 고려
- 일대다 관계를 위한 엔티티 만들고 여기에서 값 타입 사용
- 영속성 전이 (Cascade) + 고아 객체 제거 사용 > 값 타입 컬렉션처럼 사용
(예) Address를 AddressEntity로 만들기
AddressEntity.class
@Entity
@Table(name = "ADDRESS")
public class AddressEntity {
@Id @GeneratedValue
private Long id;
private Address address;
public AddressEntity(String city, String street, String zipcode) {
this.address = new Address(city, street, zipcode);
}
...
}Member.class
@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<>();웬만하면 컬렉션은 사용하지 말자. 엔티티 사용하자.
정리
엔티티 타입의 특징
- 식별자 O
- 생명주기 직접 관리
- 공유
값 타입의 특징
- 식별자 X
- 생명 주기는 엔티티에 의존
- 공유하지 않는 것이 안전
- 복사해서 사용
- 불변 객체로 만드는 것이 안전
실전 예제 6 - 값 타입 매핑
값 타입: address
@Embeddable
public class Address {
private String city;
private String street;
private String zipcode;
// generate - getter, equals, hashCode
// equals 구현할 때는 getter 사용하는 옵션 사용이 좋음
}
우당탕탕