[JPA] 자바 ORM 표준 JPA 프로그래밍 - 기본편 (값 타입)

값 타입

1. 기본값 타입

JPA의 데이터 타입 분류

엔티티 타입

@Entity로 정의하는 객체

데이터가 변해도 식별자로 지속해서 추적 가능

예) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능

값 타입

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

식별자가 없고 값만 있으므로 변경시 추적 불가

예) 숫자 100을 200으로 변경하면 완전히 다른 값으로 대체

값 타입 분류

기본값 타입

자바 기본 타입(int, double)

래퍼 클래스(Integer, Long)

String

임베디드 타입(embedded type, 복합 값 타입)

컬렉션 값 타입(collection value type)

기본값 타입

예 : String name, int age

생명 주기를 엔티티에 의존

예) 회원을 삭제하면 이름, 나이 필드도 함께 삭제

값 타입은 공유하면 안됨

예) 회원 이름 변경시 다른 회원의 이름도 함께 변경되면 안됨

참고 : 자바의 기본 타입은 절대 공유되지 않는다.

int, double 같은 기본 타입(primitive type)은 절대 공유되지 않음

기본 타입은 항상 값을 복사함

Integer 같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경 자체가 불가능

public static void main(String[] args){
    int a = 10;
    int b = a;

    b = 20;
    //기본 타입 공유 테스트
    System.out.println("a = " + a); // a = 10
    System.out.println("b = " + b); // b = 20
}

2. 임베디드 타입

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

새로운 값 타입을 직접 정의할 수 있음

JPA는 임베디드 타입(embedded type)이라 함

주로 기본 값 타입을 모아서 만들어서 복합 값 타입이라고도 함

int, String과 같은 값 타입 (엔티티 아님)

예제

회원 엔티티는 이름, 근무 시작일, 근무 종료일, 주소 도시, 주소 번지, 주소 우편번호를 가진다. => 너무 번잡하다.

회원 엔티티는 이름, 근무 기간, 집 주소를 가진다. => 이런식으로 묶어낼 수 있는게 임베디드 타입이다.

쉽게 말해서 Period, Address 클래스를 새로 만들었다고 생각하면 된다.

임베디드 타입 사용법

@Embeddable : 값 타입을 정의하는 곳에 표시

@Embedded : 값 타입을 사용하는 곳에 표시 (둘 중 하나만 넣고 생략 가능)

기본 생성자 필수

임베디드 타입의 장점

재사용

높은 응집도

Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음

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

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

DB 입장에서는 값타입을 쓰든 안 쓰든, 임베디드 타입을 쓰든 안 쓰든 회원 테이블은 똑같다. 매핑만 해주면 된다.

임베디드 타입은 엔티티의 값일 뿐이다.

임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.

객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능

잘 설계한 ORM 애플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많음

@Embeddable
public class Period {

    private LocalDateTime startDate;
    private LocalDateTime endDate;
}

@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;
    }
}

@Entity
public class Member {
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

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

    //기간 Period
    @Embedded
    private Period workPeriod;

    //주소
    @Embedded
    private Address homeAddress
}

JpaMain의 try 내부
try{
    Member member = new Member();
    member.setUsername("hello");
    member.setHomeAddress(new Address("city","street","10000"));
    member.setWorkPeriod(new Period());

    em.persist(member);
}

임베디드 타입과 연관관계

TEXT

@Embeddable
public class Address {

    private String city;
    private String street;
    @Column(name = "ZIPCODE") //이름 설정도 가능
    private String zipcode;

    private Member member; //임베디드 안에 엔티티도 들어올 수 있다.

    public Address() {
    }

    public Address(String city, String street, String zipcode) {
        this.city = city;
        this.street = street;
        this.zipcode = zipcode;
    }
}

@AttributeOverride : 속성 재정의

한 엔티티에서 같은 값 타입을 사용하면?

컬럼 명이 중복됨

@AttributeOverrides, @AttributeOverride 를 사용해서 컬럼 명 속성을 재정의

@Entity
public class Member {
    @Id
    @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

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

    //기간 Period
    @Embedded
    private Period workPeriod;

    //주소
    @Embedded
    private Address homeAddress;

    //주소
 //   @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;
}

임베디드 타입과 null

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

@MappedSuperclass vs @Embeddable

@MappedSuperclass

Entity로 정의하는 것이고 여러 Entity에 공통적으로 적용해야 할 때 사용할 수 있다.

상속이다.

상속은 다중상속도 안되고 객체지향 설계상 유연성이 떨어진다.

@Embeddable + @Embedded

Value 타입으로 정의하는 것이고 비슷한 속성을 가지는 애트리뷰트를 하나의 값으로 만들어 재사용성을 높일수 있는 방법이다.

위임이다.

JPQL을 사용할 때에는 엔티티에서 embedded type까지 쿼리하기 위해서 type을 명시해야 하는 불편함이 존재한다.

예) 위임 사용: select u from User u where u.timestamped.createdDate > ?

예) 상속 사용 : select u from User u where u.createdDate > ?

대부분의 상황에서는 embedded type을 사용하는 것이 좋겠지만 단순한 데이터를 다룰 때에는 단순한 방식(@MappedSuperclass)을 선택하여 처리하는 것이 더 나은 경우도 있다.

@MappedSuperclass를 사용하는 경우

수정시간, 등록시간, 수정자, 등록자 처럼 대부분의 엔티티들이 공통으로 사용하는 속성들을 다룰때 사용한다.

참고1
참고2

3. 값 타입과 불변 객체

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

값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함

부작용(side effect) 발생

TEXT

회원 1과 회원 2가 같은 주소를 볼 경우, city를 NewCity로 바꾸면 회원1과 회원2도 같이 NewCity로 바뀐다

의도적으로 쓰려면 값 타입을 쓰면 안되고 엔티티를 써야한다.

try{
      Address address = new Address("city", "street", "10000");

      Member member = new Member();
      member.setUsername("member1");
      member.setAddress(address);
      em.persist(member);

      Member member2 = new Member();
      member2.setUsername("member2");
      member2.setAddress(address);
      em.persist(member2);

      member.getAddress().setCity("newCity"); //member만 바뀌는게 아니라 member2까지 같이 바뀐다. (이런 버그는 잡아내기 어렵다.)
}

값 타입 복사

값 타입의 실제 인스턴스인 값을 공유하는 것은 위험

대신 값(인스턴스)를 복사해서 사용

TEXT

try {

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

            Member member = new Member();
            member.setUsername("member1");
            member.setAddress(address);
            em.persist(member);

            Address copyAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode()); //copy
            Member member2 = new Member();
            member2.setUsername("member2");
            member2.setAddress(copyAddress);
            em.persist(member2);

            member.getAddress().setCity("newCity"); //member2는 copyAddress로 저장했기 때문에 member2는 안바뀌고 member만 바뀐다.
}

객체 타입의 한계

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

문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아니라 객체 타입이다.

자바 기본 타입에 값을 대입하면 값을 복사한다.

객체 타입은 참조 값을 직접 대입하는 것을 막을 방법이 없다.

누군가 실수로 복사하지 않고 직접 대입하는 경우는 컴파일러 레벨에서 막을 방법이 없다.

객체의 공유 참조는 피할 수 없다.

기본타입(primitive type)
int a = 10;
int b = a; //기본 타입은 값을 복사
b = 4; //a 값은 10으로 유지

객체 타입
Address a = new Address("Old");
Address b = a; //객체 타입은 참조를 전달
b.setCity("New"); //a와 b는 같은 인스턴스를 가르킨다. 따라서 a, b 둘 다 바뀐다.

불변 객체

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

값 타입은 불변 객체(immutable object)로 설계해야함

불변 객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체

생성자로만 값을 설정하고 수정자(Setter)를 만들지 않으면 됨 (setter를 private로 만들어도 됨)

참고 : Integer, String은 자바가 제공하는 대표적인 불변 객체

불변이라는 작은 제약으로 큰 재앙을 막을 수 있다.

값을 바꾸고 싶다면?

Address newAddress = new Address("NewCity", address.getStreet(), address.getZipcode());
member.setAddress(newAddress);
//위 코드처럼 완전히 새로 만들어서 바꿔야한다.

값 타입은 side effect를 대비해서 불변으로 만드는걸 추천한다.

4. 값 타입의 비교

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

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

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

값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야함

값 타입의 equals() 메소드를 적절하게 재정의(주로 모든 필드 사용)

int a = 10;
int b = 10;
//a == b true
Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");
//address1 == address2 false
//address1.equals(address2) false (equals 오버라이드 전)
//address1.equals(address2) true (equals 오버라이드 후)
//Java에서는 ==비교시 참조값을 비교하기 때문에 false가 나온다.

5. 값 타입 컬렉션

TEXT

값 타입을 하나 이상 저장할 때 사용

@ElementCollection, @CollectionTable 사용

데이터베이스는 컬렉션을 같은 테이블에 저장할 수 없다.

컬렉션을 저장하기 위한 별도의 테이블이 필요함

값 타입 컬렉션 사용

값 타입 저장

값 타입 조회

값 타입 컬렉션도 지연 로딩 전략 사용

값 타입 수정

참고 : 값 타입 컬렉션은 영속성 전이(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

값 타입 컬렉션도 값 타입이기 때문에 라이프사이클이 member에 의존한다

Member

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

JpaMain의 try 내부

try {

            // 저장 예제
            Member member = new Member();
            member.setUsername("member1");
            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(); //깔끔한 상태에서 조회하기 위해 clear 해준다

            Member findMember = em.find(Member.class, member.getId()); //쿼리를 보면 Member만 가져온다. 즉, 컬렉션은 지연로딩 사용

            List<Address> addressHistory = findMember.getAddressHistory();
            for (Address address : addressHistory) {
                System.out.println("address = " + address.getCity()); //지연로딩이기 때문에 이때 쿼리가 나감
            }

            //수정 예제
            //homeCity -> newCity
//            findMember.getHomeAddress().setCity("newCity"); //immutable 해야하기 때문에 이런식으로 변경하면 절대 안된다.

            Address a = findMember.getHomeAddress();
            findMember.setHomeAddress(new Address("newCity", a.getStreet(), a.getZipcode())); //이런식으로 완전히 교체를 해줘야한다.

            //치킨 -> 한식
            //단순 String이기 때문에 remove로 지우고 add로 추가해야한다.
            //String은 업데이트가 없다.
            findMember.getFavoriteFoods().remove("치킨");
            findMember.getFavoriteFoods().add("한식");

            //old1 -> newCity1
            findMember.getAddressHistory().remove(new Address("old1", "street", "10000"));
            //remove의 기본 동작은 equals로 대상을 찾는다. 즉, equals, hashcode를 안넣으면 지워지지 않고 값이 계속 들어가게 된다.
            findMember.getAddressHistory().add(new Address("newCity1", "street", "10000"));
            // 출력 결과 : MEMBER_ID를 기준으로 ADDRESS 테이블의 모든 컬럼이 delete가 되고 기존의 테이터인 old2와 새로운 데이터인 newCity1이 insert가 된다.
            // 결론 : 쓰면안됨
}

값 타입 컬렉션의 제약사항

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

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

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

값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야함 : null 입력 X, 중복 저장 X

값 타입 컬렉션 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려 (실무에서 많이 쓰임)

일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용

영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용

EX) AddressEntity

값타입 컬렉션은 언제쓰이나?

엄청 단순할때 사용 (업데이트 필요 없을 때, 추적할 필요 없을 때)

AddressEntity

    @Id @GeneratedValue
    private Long id;

    public AddressEntity() {
    }

    public AddressEntity(Address address) {
        this.address = address;
    }

    private Address address;

    public AddressEntity(String city, String street, String zipcode) {
        this.address = new Address(city, street, zipcode);
    }

Member

    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    @JoinColumn(name = "MEMBER_ID")
    private List<AddressEntity> addressHistory = new ArrayList<>();

정리

엔티티 타입의 특징

식별자 O

생명 주기 관리

공유

값 타입 특징

식별자 X

생명 주기를 엔티티에 의존

공유하지 않는 것이 안전(복사해서 사용)

불변 객체로 만드는 것이 안전

값 타입은 정말 값 타입이라 판단 될 때만 사용

엔티티와 값 타입을 혼동해서 엔티티를 값 타입으로 만들면 안됨

식별자가 필요하고, 지속해서 값을 추적, 변경해야 한다면 그것은 값 타입이 아닌 엔티티

Quiz

문제 1. 다음 코드의 상황별 출력 결과를 쓰시오.

Address address1 = new Address("city", "street", "10000");
Address address2 = new Address("city", "street", "10000");

상황 1. == 비교
System.out.println(address1 == address2)

상황 2. equals 비교, Address에 equals() 메소드 오버라이드 안함
System.out.println(address1.equals(address2))

상황 3. equals 비교, Address에 equals() 메소드 오버라이드 함
System.out.println(address1.equals(address2))

정답 확인

1. false

2. false

3. true

== 비교는 참조값을 비교하기 때문에 false가 나온다.
equals()의 기본은 == 비교이기 때문에 false가 나온다.
equals() 메소드를 재정의할 경우 내부 값이 같은지 판별하기 때문에 true가 나온다.

문제 2. 비슷한 기능을 가진 @MappedSuperclass와 @Embeddable의 차이점을 생각해보자.

정답 확인

@MappedSuperclass는 상속
@Embeddable은 위임

자세한 설명

Twitter Facebook LinkedIn

김경호

[JPA] 자바 ORM 표준 JPA 프로그래밍 - 기본편 (값 타입)

값 타입

1. 기본값 타입

2. 임베디드 타입

@MappedSuperclass vs @Embeddable

3. 값 타입과 불변 객체

4. 값 타입의 비교

5. 값 타입 컬렉션

Quiz

1. false

2. false

3. true

공유하기

댓글남기기

참고

[Daily Contents] IT Trends

[Daily Contents] 주니어 개발자 성장 촉진제

[Daily Contents] 정규 표현식

[Daily Contents] 테스트주도개발 TDD