단방향 연관관계
객체와 테이블 연관관계 차이 이해
객체의 참조와 테이블의 외래 키를 매핑
방향 : 단방향, 양방향
다중성 : 다대일 ,일대다 , 일대일...
연관관계의 주인 : 객체 양방향 연관관계는 관리 주인이 필요 (가장 중요)
객체를 테이블에 맞추어 모델링 할경우 ?
내부적으로 Sequence 써서 멤버 아이디는 2임.
-> 데이터 중심으로 모델링하면 협력 관계 못만듬.
외래키 조인해서 연관 테이블을 찾기 때문에..
객체는 참조를 사용해서 연관관계를 찾는다.
테이블과 객체는 위 예시처럼 큰차이가 있다.
단방향 관계
객체 지향 모델링
양방향 연관관계와 연관관계의 주인
양방향 관계
테이블 연관관계는 외래키가 있기 때문에 딱히 변화가 없음
테이블 연관관계는 외래키 하나로 연관관계를 다 알수있다.
객체는 셋팅해줘야 된다 .
연관관계의 주인과 mappedBy
mappeBy 정체는?
객체와 테이블간에 연관관계를 맺는 차이를 이해해야 한다.
단방향 관계 2개이다 멤버 -> 팀 / 팀 -> 멤버
테이블은 외래키 하나로 양쪽을 다 알 수 있다.
외래키 하나로 연관관계가 끝남. (방향이 딱히 없는 듯...)
객체는.. 참조가 양쪽 객체에 있어야 된다.
멤버의 팀을 바꾸고 싶을 때
양방향일때..
멤버객체의 팀을 변경해야되나? 팀 객체 멤버스에서 수정을 해야되나..?
그래서 둘 중 하나로 외래키를 관리해야된다.
연관관계 주인
mappded by 내가 저거에 의해 맵핑이 되있어 (주인이 아님)
읽기만 가능.. Team 객체는 members 조회만 가능하고 업데이트는 안됌.
누구를 주인으로..!?
외래 키가 있는 곳을 주인으로 정해자.
여기서는 Member.team이 연관관계 주인.
Team members는 가짜 매핑 (읽기전용) Member team 진짜 매핑
Team이 주인이 된다면? 멤버스에 업데이트 하면 다른테이블에 업데이트가 된다
ex) Team 객체 멤버스 업데이트하면 Member 테이블 Update가 된다. 이게 이상함.
외래키가 있는 곳이 왜 주인?
DB입장에선 외래키 있는 곳이 무조건 다 없는곳이 1
그 말인 즉슨 N 쪽이 무조건 주인
양방향 매핑시 가장 많이 하는 실수
- 연관관계 주인에 값을 입력하지 않음
mappedby 로 인해 members는 읽기 전용이기 때문에
양방향에선 (객체지향적 입장) 둘다 값을 넣어주는게 JPA 입장에서 맞다.
team.getMembers().add(member) 를 안넣어주면?
flush() clear() 없애버리면?
영속성 컨텍스트안에 들어가 메모리 상에만 존재하기 때문에..
- 테스트 케이스 작성시에도..
결론 : 양방향 연관관계에서는 양쪽에 다 값을 셋팅해줘야된다.
추천 하는 방법 **
Member 객체 setTeam(이름을 teamChange로 해주면 더 좋다 )
해줄 때 이런식으로 작성해준다. 반대편에서 해줘도된다. Team객체
(연관관계 편의 메소드)
무한 루프 조심
toString()일경우 양쪽 계속 호출..
컨트롤러(api)에서 entity자체를 반환하면.. 무한루프 / api 스펙도 바뀜
Dto로 변환해서 반환하자.
처음 설계를 할 때.
단방향 매핑으로 설계를 일단 완료하자.
테이블과 객체를 같이 설계 하면서 .
다 쪽에서 단방향 매핑 다들어가야 된다.
JPA에서는 단방향 매핑만으로 이미 완료가 됨
객체 관점에서 매핑은 끝남
실전 예제 2 - 연관관계 매핑
단방향 연관관계부터!
외래키 중심으로 주인 정하고 연관관계 정하기
먼저 고민해야될 부분?
Member 1 / Order N
양방향 해서 바로 멤버쪽에 바로 넣었을 수있지만
가급적 단방향 으로 우선 설계 양방향하면 복잡해지기 때문
그래서 양방향으로 할 경우 나중에 필요에 의해서 객체에 mappedBy를 넣어준다.
아이템은 변경이 없는 이유?
연관관계 참조가 없는 이유.
상품 입장에선 어떤 주문에 의해서 상품이 선택 되있는지 중요하지 않다.
상품 자체를 보고 어떤 주문으로 팔렸는지? 중요하지 않다.
Member 에 Orders 넣는건 별로 좋지 않다.
Order 테이블에 이미 외래키가 있으니 (테이블관점?)
관심사를 끊어내야될건 끊어내야된다. 설계 할때 좀 어려울 듯 이부분은.
여기서는 그냥 예제니 Member에 Order를 넣어 양방향 만들어 줌
양방향일때 mappedBy 부분
이부분은 없어도 딱히 문제가 없다.
ex)
양방향 연관관계가 아니라도 개발하는데 문제가 없다.
실전에선 JPQL 을 작성하게 되는 데
복잡하게 짜는 이유 때문에 양방향이 필요성이 있다
할 수 있으면 최대한 단방향
실무에서는 조회나 편하게 작성하려고 하기 때문에 양방향으로 하는 것이 많다.
