저번에 작성했던 연관관계 맵핑 부분에 대해 다시복습도하고 좀 더내용을 추가 하였다.

연관관계 맵핑

• 이런식으로 연관관계를 만들어준다. 중요한점은 객체와 테이블의 연관관계의 차이점을 아는것이 가장 중요하다.

• 객체연관관계를 설정 해준다. (참조 대신에 외래키를 그대로 사용)
• 이러한 방식을 데이터 중심 설계라 한다.
• 객체를 테이블에 맞춰 모델링 (테이블 위주)

  이러한 데이터 중심설계의 문제점!!!!

-> 객체를 테이블에 맞추어 데이터 중심설계로 가면 협력관계를 만들수 없다.

-> 조회하거나 수정을 할떄 맴버 객체 얻어오고 ,아이디 얻어오고 팀 객체얻어오고 아이디얻어오고..... 객체지향이 아니다!

테이블 vs객체 차이점

1. 테이블은 외래 키로 조인을 사용해서 연관된 테이블을 찾는다.
2. 객체는 참조를 사용해서 연관된 객체를 찾는다.

객체지향 모델링

• 객체지향으로 모델링을 맴버객체를 불러와 바로 팀객체를 참조 할수 있다!

양방향 연관관계

• 자유롭게 양쪽에서 조회가능!

• 양방향 연관관계를 당하는(?) 쪽에서는 꼭 mappedBy를 써줘야한다.

• 객체의 양방향은 사실 단방향 두개이다

• 테이블은 fk 하나로 양쪽 자유롭게 (양방향) 가능 하다.

연관관계 주인

양방향 매핑 규칙

• 객체의 두 관계중 하나를 연관관계의 주인으로 지정

• 연관관계의 주인만이 외래 키를 관리(등록, 수정)

• 주인이 아닌쪽은 읽기만 가능

• 주인은 mappedBy 속성 사용X

• 주인이 아니면 mappedBy 속성으로 주인 지정'

• 다대일 경우 '다' 쪽이 무조건 fk를 가지고 연관관계 주인이다.

-핵심-
단방향으로도 맵핑이 끝나니 될수 있으면 단방향으로하고 나중에 필요할때(조회) 그때 양방향으로 만든다. 굳이 양방향으로 스타트 할필요 없다.

추가적내용 + 정리

1. 양방향일때는 수정 삭제 할때 주인에다가 하는게 맞지만 사실상 양방향에 넣어줘야한다

2. flus(),clear() 가 있으면 db에서 값을 가져와 fk 를(테이블) 이용해 연관된 값을 다 가져오기때문에 양방향에 값을 설정 안해도 되지만
   이 두개가 없으면 양방향 설정해줘야함 그냥 그 저장상태 그대로 1차캐시에서 가져오기때문에

-> 편의메서드 만들자

3. controller 에서 반환 entity 반환하지말자 -> entity 를 api로 반환해버리면 entity를변경하는 순간 api스펙이 바뀌어버리기때문 dto 로 변환해서 반환!

4. 양방향 말고 단방향으로 최대한 끝내자 / 처음에는 단방향으로 설계 끝내야함 / 단방향 잘해놓으면 양방향은 필요할떄 추가만 하면된다

5. 양방향 매핑은 반대 방향으로 조회 기능이 추가된것뿐