CH02 핵심개념이해 2
Last updated
Last updated
처음에 ‘엔티티 매핑’이라는 제목만 보고 ‘이게 뭘 말하는 거지?’ 하는 생각이 들었는데, 강의를 들어보니 자주 썼던 어노테이션들 이었다. 내가 만약 ORM 의 근본적인 방향성을 잘 이해하고 있는 상태였다면 ‘엔티티 매핑’ 이라는 단어만 보고 Object - Relation 의 매핑을 의미한다는 것을 떠올렸을 것 같다. 그리고 평소에 어노테이션들을 쓸 때도 결국 이 정보들이 메타 데이터로서 하이버네이트가 Object 와 Relation 을 매핑할 수 있도록 활용된다는 것을 생각하면서 썼을 것 이다.
그만큼 기술의 근본적인 방향성이나 목적에 대한 고민 없이 기계적으로 써왔다는 생각이 들었다.
구체적으로 하나하나 어노테이션들을 정리하는 것은 큰 의미가 없는 것 같아 생략하고, 강의 중에 나온 생각해봄직한 포인트들만 정리한다.
@Entity 에는 name 필드가 있다. Object 관점에서 해당 객체의 이름을 뜻하는 것인데, @Table 의 name 은 특별히 써주지 않을 경우 @Entity 의 name을 따라간다. 그리고 @Entity 의 name 의 기본 값은 해당 class 의 이름이다.
즉, 아무것도 안써주고 @Entity 만 쓸 경우 @Entity 의 name 은 class 명을 따라가고, @Table 의 name 은 @Entity 의 name 을 따라가므로 결국 해당 class 명이 곧 table 명이 되는 것이다.
primitive type 이 더 적절한 것 같다. 왜냐하면 primitive type의 경우 지정해주지 않으면 0이 되는데, 이는 주 키가 0인 Relation 의 row와 같다는 뜻이 되기 때문이다. 따라서 명시적으로 nullable 한 타입의 지정이 더 알맞은 판단인 것 같다.
라는 단어가 어원이 프로그래밍이라는 것도 이번에 알았다. ‘일시적으로 잠시 체류하는’이라는 의미이다. 해당 클래스의 멤버 필드로 사용하고 싶지만 컬럼으로는 맵핑하고 싶지 않을때 사용하는 어노테이션이다. 실무에서도 연산의 결과값 등으로 잠시 갖고 있게 할 필요성이 있을때 사용했었다.
Entity와 Value를 가르는 기준은 식별자가 있는지이다. 식별자가 있다는 의미가 곧 독립적으로 존재하는지, 아니면 어딘가에 속해야하는지를 말한다. Entity 의 필드들 전부를 Value 라고 표현할 수 있으며 Enum, @Embeddable, @Embedded 등을 이용해서 매핑하는 것들을 의미한다.
엔티티간에는 ‘관계’가 존재한다. 여기서 ‘관계’란 엔티티간에 도메인 개념으로 가지게 되는 연관성이며 영속성 관리 차원에서는 1, N 과 같은 표현으로 수에 관심을 둔다.
‘관계’에는 반드시 주인이 있는데, 주인은 관계를 정의하는 엔티티가 곧 주인이다. 관계를 정의한다는 의미는 두 엔티티 간에 관계가 어떤지에 관해서 메타 데이터를 가지고서 ‘이 두 엔티티는 이런 관계를 갖고 있어’라고 정의하는 것을 의미한다. 당연히 이렇게 관계를 정의하는 엔티티의 테이블에 관계에 대한 데이터(외래키)가 들어가게 된다.
여기서 ‘방향’의 의미는 Relation의 관점이 아니라 Object 관점에서의 개념이다. A 라는 Object 를 조회하고자 할 때 이를 B라는 Object를 통해서 조회가 가능하다면 여기서 A 와 B 는 방향을 가지고 있는 것이다.
A 에서 B 가 조회가 가능하거나 혹은 그 반대일때 모두 ‘단방향’이라고 할 수 있으며, A 와 B 둘다 서로 서로를 통해 조회가 가능한 경우 이를 ‘양방향’이라고 할 수 있다.
@ManyToOne 으로 단방향 설정을 해줄 경우, 주인 Entity에 외래키가 생성되며, @OneToMany 로 단방향 설정을 해줄 경우, 관계 테이블이 생성된다.
@ManyToOne, @OneToMany 모두 사용하여 양방향을 형성해줄 경우 @OneToMany의 mappedBy 를 통해서 주인 entity 에서 다뤄지고 있는 필드를 반드시 설정해주어야 하며, 외래키 입력을 위해서 주인 entity의 필드에 반드시 관계를 가진 entity 를 값으로 설정해주고 save 처리를 해주어야 insert 실행시 외래키가 생성된다.
FK 로 맺어진 관계의 엔티티에서 FK 정보를 저장하기 위해서는 ‘주인’ 엔티티에 관계 정보를 set 해줘야한다. 이 시점에서 Relation의 관점에서는 이미 필요한 정보의 set이 완료된 상태이지만, Object 의 관점에서는 주인이 아닌 쪽의 객체가 가진 Set에도 주인 Entity 를 add 해주지 않으면 조회를 다시해오지 않은 상태에서는 정합성이 깨진 상태이므로, Set 에도 add를 해주는 것이 좋다.