오늘의 학습 키워드 💻
▸ 오늘의 코드카타
▸ 영속성 컨텍스트
▸ 연관관계
✅ 오늘의 코드카타
✅ 영속성 컨텍스트
- 영속 엔티티/객체
- 영속 컨텍스트
- 일종의 메모리 저장소
- EntityManager가 관리할 엔티티 객체 보관
- EntityManager가 내부적으로 동작을 함
- @Transactional을 걸어야 업데이트가 됨
- 동작원리
- 영속성 컨텍스트를 해제하는 detach 같은 기능이 있지만 웬만해서는 사용하지 않음
=> 유지 보수가 어려워지기 때문에
- 유지보수하기 좋게 하기 위헤 웬만하면 EntityManager를 직접 건드리는 일은 없도록 하자
1. @Entity
- JPA가 관리해주는 DB 테이블과 매핑되는 클래스
- 반드시 기본 생성자가 클래스에 포함되어 있어야한다. -> @NoArgsConstructor
- 다양한 클래스들이 있을 때 이 클래스들이 가지고 있는 필드가 모두 다르다.
- 라이브러리에서 이 클래스들을 사용하기 위해 이 클래스들로 객체를 생성할 때 필요
- @NoArgsConstructor가 있어야만 동작을 함, 아니면 기본 생성자가 있어야함
2. 데이터 스키마 자동 생성
hibernate.hbm2ddl.auto
옵션 | 설정 |
---|
create | 생성 (기존테이블 삭제) |
create-drop | 생성 + 종료 시 테이블 삭제 |
update | 변경 사항에 대해 update |
validate | 엔티티와 테이블 매핑 확인 |
none | 아무 동작하지 않음 |
-> 실무에서는 create, create-drop, update 절대 사용 금지
3. @Enumrated
EnumType.ORDINAL
과 EnumType.String
두가지를 사용할 수 있음 default는 ordinal
- 하지만 순서가 변경될 여지가 많기 때문에 EnumType.String 사용
4. @Temporal
- 더 이상 사용하지 않음 -> 있으면 옛날 코드
5. @Transient
- Entity에 실제 데이터에 저장되는 값은 아니고 Entity에 매핑시켜주고싶은 값을 지정할 때 사용
- 웬만하면 사용하지 않는다. DTO 활용
6. @GeneratedValue
- MySQL에서는 GenarationType.IDENTIFY 사용
✅ 연관관계
1. 단방향
@OneToOne
- 단방향은 성능상으로 사용하지 않는 편이 좋음
- 테이블을 늘리는 것은 좋지 않기 때문에 웬만하면 사용하지 말자
- 예를 들어, 유저와 유저프로필은 한 테이블에서 가능함
- 쪼개지말고 웬만하면 한 테이블 안에서 처리
- @OneToOne을 사용하고자 할 때, 굳이 테이블을 쪼개야하는지 충분히 고민하고 사용
- 유지보수하기 불편함
@ManyToOne
- 우리가 사실 사용할 어노테이션은 @ManyToOne 밖에 없음
- @OneToMany는 양방향을 사용하지 않기 때문에 실제로 사용하지 않음
연관관계 주인을 결정하는 법
- 1:N 관계일 때, N 쪽이 주인
- 예를 들어 한명의 유저는 여러 개의 댓글을 작성할 수 있으므로 댓글이 연관관계의 주인
2. 양방향
- @ManyToMany는 절대 사용하지 않음, 중간 테이블을 만들어서 풀어준다.
- 실무에서 양방향은 사용하지 않는다.
- DB에 양방향은 원래 존재하지 않는다.
- 양방향은 JPA에서 제공해주는 기능이다.
- 하지만, 양방향을 사용하지 않는다면 순환참조 에러에 직면할 수 있다.
- -> DTO를 통해서 순환참조를 예방할 수 있다.
양방향을 사용하지 말자
- DB 관점에서는 양방향 관계는 존재하지 않는다.
- 단방향 관계여도 서로 연결되어 접근할 수 있기 때문이다.
- @OneToMany는 실제로 없다 -> 사용한 순간 JPA가 어려워지고 버그가 많이 생기고 유지보수가 어려워짐