자바 ORM 표준 JPA 기본편

728x90

JPA의 최상위 데이터 타입 분류

JPA는 데이터 타입을 최상위 레벨로 보면 두가지로 나뉜다.
엔티티 타입과 값타임

1. 값 타입

int, Integer, String처럼 단순히 값을 사용하는 자바 기본 타입이나 객체
식별자가 없고 값만 있으므로 변경시 추적이 불가하다.

2. 엔티티 타입 (내장타입)

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

값 타입의 분류

1. 기본값 타입

자바 기본 타입 (int, double 등..)
래퍼 클래스 (Integer, Long 등..)
String
- 기본 타입은 항상 값을 복사한다
- Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경이 불가하다

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

JPA에서는 새로운 값 타입을 직접 정의하여 사용이 가능하다.
임베디드 타입은 엔티티의 값일 뿐이다.
임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다(중요)
객체와 테이블을 아주 세밀하게 매핑하는 것이 가능하다
잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음

임베디드 타입

임베디드 사용법

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

@Embeddable
public class Address {

    private String city;
    private String street;
    private String zipcode;

    public Address() { // 기본생성자 필수 
    }
}
@Embeddable
public class Period {

    private LocalDateTime startDate;
    private LocalDateTime endDate;

    public Period() { // 기본생성자 필수 
    }
}
public class Member {

	@Id @GeneratedValue
    	@Column(name = "MEMBER_ID")
    	private Long id;

    	@Column(name = "USERNAME")
    	private String username;
        
        //period
    	@Embedded
    	private Period period;

    	//address
    	@Embedded
    	private Address homeAddress;
        
 }

임베디드 타입의 장점

재사용성
높은 응집도
값 타입별 의미있는 메소드를 만들 수 있다.

값 타입과 불변 객체

값 타입은 굳이 왜 엔티티 값을 분류하고 나눌까?

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

따라서 값 타입은 단순하고 안전하게 다룰 수 있어야한다.

값 타입 공유 참조
- 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험하다
- 부작용 발생 (side effect)

값 타입 복사
- 값 타입의 실제 인스턴스인 값을 공유하는 것은 위험하다
- 대신 값(인스턴스)를 복사해서 사용

위 그림과 같이 회원1과 회원2의 주소가 우연히 같아서, 하나의 Address객체를 만든 뒤 같이 넣어주면 값을 공유하게 된다.

Address address = new Address("city","street","zipcode");

Member member1 = new Member();
member1.setUsername("A");
member1.setAddress(address);

Member member2 = new Member();
member2.setUsername("B");
member2.setAddress(member1.getAddress());

이렇게되면 회원1이나 2가 이후 주소를 변경해도 함께 변경되기 때문에 문제가 생길 수 있다.

해결 방법 : 값 타입의 실제 인스턴스인 값을 공유하는 방식 대신, 값(인스턴스)를 복사해서 사용한다.

객체 타입의 한계

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

기본 타입(primitive type)

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

객체 타입

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

또 다른 해결 방법 이를 불변객체로 만드는 것이다.

불변 객체

불변객체란 생성 시점이후에 변경할 수 없는 객체로 Integer, String 등이 이에 속한다.

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

public String getCity() {
        return city;
    }

    public String getStreet() {
        return street;
    }

    public String getZipcode() {
        return zipcode;
    }

값 타입 비교

1. 동일성 비교

인스턴스의 참조 값을 비교한다.
== 을 이용해서 비교하는 방법.

int a = 10;
int b = a; // 기본타입으로, 공유 x
int c = 10;
a = 20;

System.out.println("a = " + a);  // a = 20
System.out.println("b = " + b);  // b = 10
System.out.println("c = " + c);  // c = 10
  
System.out.println("b == c : " + (b == c));  // b == c : true
System.out.println("b = " + System.identityHashCode(b));  // b = 157627094
System.out.println("c = " + System.identityHashCode(c));  // c = 157627094

2. 동등성 비교

equals() 사용해서 인스턴스의 값을 비교한다.
자바의 기본타입을 제외하고는 동등성 비교를 해줘야 값만 비교가 가능하다.
임베디드 타입

값 타입은 자바의 기본타입을 제외하고는 모두 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);
    }

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

•참고 문헌 : 자바 ORM 표준 JPA 프로그래밍 / 김영한

코딩 가득

자바 ORM 표준 JPA 기본편 - 값 타입