- 연관관계
- 방향(direction)
- ‘방향’ 의 개념이 무엇이고 왜 중요한지
- ‘양방향’의 장점
- 다중성(multiplicity)
- 관계의 주인(owner)
- 방향(direction)
- 양방향 연관관계시 주의점
- 관계의 주인 뿐만이 아니라 반대편에도 데이터를 맞춰주어야 한다
- Entity 를 그대로 반환하지 말라
연관관계
복잡한 비즈니스 상에서는 여러 엔티티가 설계되고 엔티티간에 상관관계가 존재할 수 있다. 이를 테이블의 세계에서는 외래키라는 개념으로 연관관계를 설정한다. ORM 에서 이 외래키 및 연관관계의 개념을 어떻게 설정하고 사용하는지에 관한 것이 ‘연관관계’ 이다.
연관관계 설정시 아래 세 가지 개념이 핵심이다.
방향(direction)
‘방향’ 의 개념이 무엇이고 왜 중요한지
테이블의 세계에서는 외래키 라는 개념으로 테이블간의 연관관계를 설계한다. 그리고 테이블에서는 하나의 외래키를 이용해서 연관관계가 있는 두 테이블 모두 조회가 가능하다.
예를 들어서 team 과 member가 있고 member에 외래키가 존재하는 경우 특정 teamId를 통해서 memeber들을 조회할 수 있으며, 반대로 특정 member들의 team 을 조회할 수 있다. 즉, 두 테이블 모두 하나의 외래키로 조회가 가능하다.
하지만 객체의 경우 해당 필드를 가지고 있어야만 조회가 가능하다. 즉, memeber 에서 team 을 조회하려면 member 는 team 을 필드로 갖고 있어야하며, 반대로 team 에서 member를 조회하고 싶은 경우 member 들을 필드로 갖고 있어야 한다. 그래야 참조를 할 수 있다.
이렇게 테이블의 세계에서는 외래키 하나로 member -> team, team -> member 모두 조회가 가능하지만 객체의 세계에서는 ‘객체 그래프 탐색’의 방향이 제한된다. 한쪽만 가능한 경우를 두고 ‘단방향’이라고 하며 양쪽 모두에서 서로 참조가 가능한 경우를 ‘양방향’ 이라고 한다.
‘양방향’의 장점
객체 그래프 탐색이 양방향 모두 가능하게 설정해주는 것의 장점은(=단방향과 비교하여 양방향의 장점) 그래프 탐색이 서로 참조가 가능하다는 것 뿐이다. 그리고 사실 양방향이란 단방향을 서로에게 걸어주는 것일 뿐이다.
단방향 대비 양방향의 장점은 그저 객체 그래프 탐색의 방향이 일방적이지 않고 서로 참조가 가능하다는 것 뿐이다.
다중성(multiplicity)
엔티티간의 관계에서 갖게 되는 수적인 관계에 관한 개념이다. 너무 당연한 개념이라 정리를 생략한다.
관계의 주인(owner)
궁극적으로 객체 지향 프로그래밍을 통해서 데이터베이스 세계와 소통하는 것이 ORM의 목적인데, 테이블의 세계에서는 외래키 하나만 있으면 된다. 그런데 만약 객체의 세계에서 양방향 설정을 하게 되면 외래키는 하나인데 외래키를 누가 관리해야할 것인가의 이슈가 발생한다.
즉, 관계의 주인이란 양방향 설정시 고려해야할 개념이며 ‘외래키를 관리하는 객체’가 관계의 주인이 된다.
양방향 연관관계시 주의점
관계의 주인 뿐만이 아니라 반대편에도 데이터를 맞춰주어야 한다
백기선님 강의때도 다뤘던 주제인데 연관관계를 가진 두 객체의 일관성을 유지해줘야 하는 것이 중요하다. 편의 메소드를 통해서 해결하도록 한다.
편의 메소드에 관해서 공식 문서 같은 것에서 서술하고 있는 레퍼런스를 찾고 싶은데 나오질 않아서 링크 첨부가 불가능 하다. 편의 메소드란 연관관계를 가진 두 엔티티의 싱크를 맞춰주는 메소드이다.
예를 들어 Team, Member 사이에서 연관관계의 주인인 Member에 Team 을 세팅해주고 insert 를 하면 테이블에는 데이터가 들어가지만 Team 의 Memeber 에는 해당 Memeber 가 들어가 있지 않을 것이므로 버그 방지를 위해서 객체 세계에서의 참조관계도 신경써서 처리해줘야 한다는 것이다.
추가 뿐만이 아니라 삭제 등 참조관계의 변경에서도 마찬가지다.
Entity 를 그대로 반환하지 말라
entity 를 그대로 반환하는 경우 두 가지 문제가 생길 수 있다.
첫째, 양방향 참조하는 entity 를 json 으로 변환하는 과정에서 서로 참조하고 있는 객체를 변환하면서 무한 루프에 빠지는 문제가 있다.
둘째, entity 변경이 발생하면 API 스펙이 바뀌어버리게 된다.
따라서 위와 같은 문제점들 때문에 entity 를 dto 로 변환해서 반환하여야 한다.