- Entity에서 String, int등의 타입을 값타입이라고 한다.
- 값타입은 공유하면 안된다.
- 새로운 값 타입을 직접 정의해서 사용할 수 있는데, jpa에서는 이것을 임베디드 타입이라 한다.
- 임베디드타입도 값타입이라는 점에 유의.
- 회원이 상세한 데이터를 그대로 가지고 있는 것은 객체지향적이지 않으며 응집력만 떨어뜨린다.
- @Embedded @Embeddable 사용.
- 임베디드 타입은 엔티티의 값일 뿐이다. 따라서 값이 속한 엔티티의 테이블에 매핑한다. 임베디드 타입을 사용하기 전과 후에 매핑하는 테이블은 같다.
- 임베디드 타입 덕분에 객체와 테이블을 아주 세밀하게(fine-grained)매핑하는 것이 가능하다. 잘 설계한 ORM 어플리케이션은 매핑한 테이블의 수보다 클래스의 수가 더 많다.
- 임베디드 타입은 값 타입을 포함하거나 엔티티를 참조할 수 있다.
- 엔티티는 공유될 수 있으므로 참조한다고 표현하고, 값 타입은 특정 주인에 소속된고 논리적인 개념상 공유되지 않으므로 포함한다고 표현했다.
- 임베디드 타입에 정의한 매핑정보를 재정의 할 떄 사용. 엔티티 자체에 걸어준다.
- 회사주소/집주소 타입에서 주소컬럼이 중복됨.
- 이 어노테이션을 너무 많이 사용하면 코드가 지저분해지지만 다행히 한 엔티티에 같은 임베디드타입을 중복해서 사용하는 일은 많지 않다.
- 임베디드 타입을 NULL로 세팅하면 관련 컬럼이 다 NULL로 세팅됨.
- 임베디드 타입 같은 값타입을 여러 엔티티에서 공유하면 위험하다.(자바 참조 타입에서 발생하는 버그와 같은 이유)
- 공유 참조로 인해 발생하는 버그.
- 임베디드 타입을 사용할 떄 항상 값을 복사해서 사용하면 공유 참조로 인해 발생하는 부작용을 피할 수 있다.
- 문제는 임베디드 타입처럼 직접 정의한 값 타입은 자바의 기본 타입이 아닌 객체 타입이라는 것이다.
- 객체를 대입할 때마다 인스턴스를 복사해서 대입하면 공유 참조를 피할 수 있다. 문제는 복사하지 않고 원본의 참조값을 직접 넘기는 것을 막을 방법이 없다는 것이다.
- 객체의 공유참조는 피할 수 없다. 따라서 근본적인 해결책이 필요한데 가장 단순한 방법은 객체의 값을 수정하지 못하게 막으면 된다.
- 객체를 분변하게 만들면 값을 수정할 수 없으므로 부작용을 원천 차단할 수 있다. 따라서 값 타입은 될 수 있으면 불볍 객체로 설계해야한다.
- 한 번 만들면 절대 변경할 수 없는 객체를 불변 객체라 한다.
- 불변 객체도 결국은 객체이기 때문에 인스턴스의 참조 값 공유를 피할 수 없지만, 수정이 불가하기때문에 사이드이펙트가 없다.
- ==(동일성) or Equals(동등성)
- Equals/Hashcode 재정의
- 관계형 데이터베이스의 테이블은 컬럼안에 컬렉션을 포함할 수 없다. 따라서 별도의 테이블을 추가하고 @CollectioNTable을 사용해서 추가한 테이블을 매핑행야한다.
- 그리고 값으로 사용되는 컬럼이 하나면 @cOLUMN을 사용해서 컬럼명을 지정할 수 있다.
- 연관관계 매핑...
- 엔티티는 식별자가 있으므로 엔티티의 값을 변경해도 식별자로 디비에 저장된 원본 데이터를 쉽게 찾아서 변경할 수 있다.
- 반면에 값 타입을 식별자 개념이 없고 단순 값들의 모음이므로 값 변경시 디비에 저장된 원본 데이터를 찾기 어렵다.
- 값 타입 컬렉션에 보관된 값 타입들은 별도의 테이블에 보관된다. 따라서 여기에 보관된 값 타입의 값이 변경되면 디비에 원본 데이터를 찾기 어려워 전체 데이터 삭제 후 재 ISNERT를 한다.
- 따라서 실무네서는 값타입 컬렉션이 매핑된 테이블에 데이터가 많다면 값타입 컬렉션 대신에 일대다 관계를 고려해야한다.
- 추가로 값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야한다. 따라서 키 제약조건으로 인해 컬럼에 NULL을 입력할 수 없고, 중복값을 저장할 수 없는 제약도 있다.
- 따라서 일대다 관계에 영속성 전이 + 고아객체 제거 기능을 적용하면 값타입 컬렉션처럼 사용할 수 있다.