JPA 직접참조 / 간접참조

아이스__아메리·2023년 2월 15일
1

JPA

목록 보기
16/18

개요

DDD에서는 왜 간접 참조를 더 권장할까? -> Article과 Comment 관계 같은 경우에도 간접 참조가 옳은걸까? 에서 시작되었다.
Aggreegate는 lifecycle 같은 연관된 객체들의 집합이지만 실무에서는 확장성을 고려해 간접참조를 개발하고 시작하는 경우가 많다.

Article과 Comment 관계 같은 경우에도 간접 참조가 옳은걸까?

직접 참조를 한다면 연관 관계 맺은 객체를 편하게 탐색할 수 있고 바뀌길 원하지 않는 참조 객체의 값이 바뀔 가능성이 있다.

성능

조회 시, 일대다 관계에서는 레이지 로딩을, 일대일 관계에서는 레이지 로딩을 해도 즉시 로딩이 되고 참조한 객체의 인스턴스 변수가 몇개든 전부 같이 조회해서 와야한다.(fetch join으로 해결가능)
하지만 id를 통한 간접 참조를 한다면 참조한 객체의 id만 조회해오게 되고 성능의 이점을 가져갈 수 있다.

라이플 사이클

Article-Comment의 경우 라이플 사이클은 Article에 종속되어 있다. 조회의 시점에 자주 탐색되는 경우 위에서 말한 성능적으로 문제가 없다면 직접참조를 고려해볼한다 생각한다.
직접참조는 조회를 주목적으로하고 조회이외의 기능을 사용하면 안된다. 하지만 JPA는 엔티티 기반으로 가져오기 때문에 comment를 조회하여 Article를 수정할 수 있는 결함이 발생하게 된다.

자바단계에서 response를 담는 것보다는 쿼리문으로 필요한 정보들만 조인해서 가져오는것이 맞긴하다. fetchJoin이든 innerJoin이든 어쨋든 조인문이 필요하고 그 정보자체는 참조하는 id만 가지고 충분히 데이터베이스 단계에서 해결이 가능하기 때문에 굳이 필요한가 싶다.

결론

직접 참조 시 장점으로는 편한 탐색, 라이플사이클을 맞춘다.
단점으로는 참조하는 객체 오용가능, 확장성 저하, 성능 저하 가능성이 있다.
참고한 문서들은 데이터구조상 설계상 직접참조가 맞다고 생각하고 나 또한 그렇게 생각한다. 하지만 실무에서는 간접참조로만 사용하고 있다.
무엇보다도 개발초기단계에서 확정성을 고려하여 간접참조하는 것이 맞지만 기본 개발단계 이후 response에서 관련된 정보 필요시 직접 참조가 필요하다. response 필요한 시점에서 현실적으로 시간이 부족하게 되는 경우가 있기 때문에 협업하는 사람들과의 소통이 필요하다.

profile
츠케멘 좋아

0개의 댓글