2-5. 엔티티 설계시 주의점

<목차>

1. 엔티티에는 Setter사용하지마라 ( Getter는 열어도 됨)

2. 모든 연관관계는 지연로딩(LAZY) 설정 -> @XToOne 은 각각 설정해주어야됨

3. 컬렉션은 필드초기화하고 손대지 말자

4. 테이블 칼럼명 생성 전략

모든 연관관계는 지연로딩으로 설정

즉시로딩 : ex) 멤버를 조회할 때 연관된 멤버를 모두 조회 ( 여러개 연관 되어있으면 하나 조회하면 다 끌고와서 문제 )

-> 연관된 데이터 다 가져와서 난리남.

-> 기

fetch join : lazy로 세팅 해놔도 필요한 엔티티를 골라서 가져올 수 있음.

N + 1 : 1이 맨 첫 쿼리 + 나머지는 딸려오는 쿼리들....망함..

@XToOne : 기본 fetch 전략이 EAGER ( 하나만 가져오니까 바로....일리는 있음 )

@XTOMany : 기본 fetch 전략이 LAZY

코드에서 찾기 : Shift + Ctrl + F 너무사기다...

한 번 감싸는 이유 : 하이버네이트가 이 컬렉션의 변경을 추적해야되기 때문에 -> 본인에 맞는 타입으로 바꿔버림. ( 만약 중간에 누군가가 컬렉션을 변경하면 하이버네이트 뜻대로 안움직인다. )

=> 컬렉션은 선언 동시에 초기화

3. 테이블, 컬럼명 생성 전략

ex)

---------------------------------------------------번외 : cascade = CascadeType.ALL 설명

일단,,,

( 원래 모든 엔티티는 persist(저장) 하고 싶으면 각각 해줘야됨. )

엔티티 당 각각 persist 호출 해야됨.

하지만 cascade 를 두면 persist(order) 만 하면 됨. - > cascade 는 persist를 전파. -> 클래스인 order만 persist 하면 List 필드에 있는 모든 객체를 자동으로 persist -> delete 할 떄도 마찬가지.

delivery 도 보면 cascade 해주었는데,,, 이것도 마찬가지로 order를 persist 해주면 delivery도 자동으로 persist 된다.

( 원래 모든 엔티티는 persist(저장) 하고 싶으면 각각 해줘야됨. )

------------------------------------------------------------------------연관관계 편의메서드 ( 딱히 이해안해도됨 )

Order 와 Item이 양방향이므로 서로 해줘야한다.

둘 중 컬트롤 하는 놈이 들고 있는게 좋다.

Order와 Delivery도 양방향이므로 연관관계 편의메서드 있으면 좋다.

( 양쪽 세팅을 코드 하나로 해결 )

-------------------------------------------------------------------------------------- 다음 장인데 양이 적어서 여기 넣어둠.

# 애플리케이션 아키텍쳐

방향은 단방향이되 간단한 거 조회할 때는 컨트롤러에서 리파지토리에 접근 가능하도록 할 예정.

( 지금 도메인은 거의 설계 끝난 상태 : 추가 비지니스 메서드가 추가될 예정 )

개발 순서 : 서비스 -> 리포지토리 -> 테스트케이스 -> 마지막에 웹 계층 적용(컨트롤러)

Develop