기본값 타입
JPA 데이터 타입 분류
엔티티 타입
@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속적해서 추적 가능?
EX) 회원 엔티티의 키나 나이 값을 변경해도 식별자로 인식 가능
(식별자 = PK 개념으로 이해하면될듯)
값 타입
Int , Integer, String 처럼 단순히 값으로 사용하는 자바 기본 타입 이나 객체
값만 있으므로 변경시 추적 불가..
ex) 숫자 100 -> 200 변경하면 완전히 다른값 으로 대체
값 타입
기본 값 타입 / 임베디드 타입 / 컬렉션 값 타입이 있다
임베디드 포지션 같은 값타입?
x,y좌표 값이 있는대 묶어서 표현 ->postion 커스텀해서 쓰는 값
기본값 타입
String name / int age
생명주기를 엔티티의 의존..
회원을 삭제하면 이름 나이 필드도 함께 삭제
값 타입은 공유하면 안됌!!
ex) 회원이름 변경시-> 다른사람도 변경되니까
주소값이 복사 된다.
공유는 가능하지만 변경이 안됀다.
int 경우는 값이 복사 됨.
임베디드 타입
엔티티 같은 값이 아니다..
-> 회원 엔티티는 이름 , 근무기간 , 집 주소를 같는다.
이런식으로 묶어 낼 수 있는게 임베디드 타입.
Period / Address 타입을 만들어 냈다.
쉽게 얘기해서 클래스 2개를 빼뒀따.
장점
재사용이 가능하면서 응집도가 높다.
Period.isWork() 처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만듬
->객체 지향적 설계
임베디드 타입을 포함한 모든 값 타입은 값 타입을 소유한 엔티티에 생명주기를 의존함
회원 테이블은 같지만
객체는 매핑만 ..
어노테이션은 객체랑 선언한 두곳 다써준다
PhoneNumber -> PhoneEntity 가지고 있음
같은 컬럼을 사용할 때 저런식으로 변경가능.
++ 임베디드 값이 NULL 이면 임베디드안에 값들은 다 NULL이 된다.
값 타입과 불변 객체
값 타입은 복잡한 객체 세상을 조금이라도 단순화하려고 만든 개념
-> 단순하고 안전하게 다 룰 수 있어야 한다.
값 타입 공유 참조
-> 임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함..
부작용 발생!
update 가 두번 일어난다..
이런식으로 바꿔야됨 .
기본 타입은 값이 복사개념이라 수정이 가능하지만..
객체타입은 주소값을 넘겨주기 때문에
참조 값을 직접 대입하는건 못막음
불변 객체
객체 타입을 수정 못하게 부작용 원천 차단
-> 값 타입은 불변 객체(Immutable object)로 설계해야함
불변객체 : 생성 시점 이후 절대 값을 변경할 수 없는 객체..
생성자로만 값을 설정하고 수정자는 만들면 안돼요
참조 Integer / String 자바가 제공하는 대표적인 불변객체
결론 -> 불변으로 부작용을 최대한 막는다.
setter 없이..
값 타입 비교
하지만 주소값 일 경우?
틀리지..
이퀄스 메소드를 객체에 자동으로 선언해 줘야 된다.
그래야 equals true가 나옴
값 타임 컬렉션
디비로 표현하기가 좀 어렵다?
컬렉션 구조로 값을 넣기 어렵다.
셋팅..
설명 .
컬렉션은 1:N 개념이라 한 테이블에 다 넣을 수 없다.
member 객체의 라이플싸이클을 의존한다 / 그리고 모두 값 타입이다..
1:N 관계랑 비슷하다.
컬렉션은 지연 로딩이다.
수정하려면 불변 객체이기때문에 새로 넣어줘야 된다. (통으로 교체)
값 타입은 업데이트 자체를 하면 안돼기때문에..
음식 객체는 안그랬는데 왜..?
3번 문항을보면 음식 객체는 불변이 적용된 String 이고 AddressHistory는 객체 리스트
이기때문에 참조값이라... 다 지우고 다시 다넣는거 같다.
결론적으로 쓰면 안됌..
중간의 값을 변경하면 추적하기가 너무 어렵다..
이런식으로 해결.
그러면 값타입 컬렉션은 언제?
콤보박스 같은거 쓸때 ..
실전예제 6- 값 타입 매핑
Equals , hash 코드 구현할때 이옵션을 체크해주자
getter를 호출하고 필드에 직접 접근하지 않는다.
Proxy일때 계산이 안돼기 때문에.
임베디드값 각각 만들어주기
