[일반] 실무에서는 JPA 어떤식으로 사용함?

[익명(58.29)]

어떤 서비스 메서드 하나를 실행하기 위해서

도메인A, 도메인B, 도메인C가 필요하다고 하면

각각의 리포지토리에서 findById로 각자 찾아서 가져옴?

아니면 페치 조인으로 연관된 애들은 한번에 가져오나?

비즈니스 로직을 짜다보면 같은 기능 내에서도

A의 조건에 따라 B가 필요할 때도 있고 필요치 않을 때도 있을텐데

그럴 때는 또 어떻게 사용하는지 궁금함

[익명(58.29)]

select 쿼리 여러번 날아가는거 감안하고 각기 findById로 찾는지 아니면 join으로 전부 한번에 가져오는지

[익명(hheee)]

댓글 참조
https://m.dcinside.com/board/backend/4780

[익명(hheee)]

약간 다른 내용인것같긴 한데

[백갤러 1(219.241)]

원래 하던 고민이긴한데 저 댓글보고 글 올림ㅇㅇ SELECT 쿼리 횟수가 증가하는 것과 서비스 하나에서 너무 많은 리포지토리에 의존하는 것은 큰 문제가 되지 않는다고 판단한 결과인가 해서. 객체지향적으로 비즈니스 로직을 짜는 것과, 꼭 필요한 테이블만을 조인 쿼리로 가져오는 것, 나아가선 1차 캐시를 최대한 활용할 수는 없을지에 대해 고민하고 있거든.

[익명(qwebnm9)]

당연한 답: 경우에 따라 다르다

[익명(qwebnm9)]

각각 찾을수도 조인 때릴수도 있다

[백갤러 1(219.241)]

그럼 하나 더. 연관 엔티티 처리는 어떻게 하고 있음? 외래키(또는 논리적 외래키)만을 갖고 있게 하는가 아니면 흔한 예시들처럼 연관 엔티티를 포함하는가? 아키텍처에 정답이 없다고는 하지만 근래에 날 너무 괴롭히는 문제들이라ㅜ

[익명(qwebnm9)]

이것 조차도 경우에 따라 다르다. 보통 연관성이 아주 깊으면 객체로 갖고 있고 아니면 키만 갖고 있음. 애초에 실제 db엔 fk 걸지도 않는 경우가 대부분이라 보통 키만 갖고있긴 함

[익명(qwebnm9)]

내가 주로 보는 기준은 연관된 객체가 항상 함께 생성되고 파괴되느냐임. 그렇다면 연관성이 상당히 크다고 볼수 있어서 엔티티를 포함하는걸 고려할 조건이 됨.

[익명(58.29)]

맞아 외래키안걸면 사실상 무조건 연관 엔티티를 직접 가지면 안되겠더라.. 해결 방법이 없는 건 아니지만 어떤 식이든 합당한 근거를 가지고 설계하면 되겠구나

[익명(qwebnm9)]

맞음 개발에 정해진 답은 없고 합당한 근거로 설계를 진행하면됨. 나중에 왜 이렇게 했죠?에 대답할 수만 있으면 됨

[백갤러 4(14.35)]

오키오키 고마워유

[백갤러 2(1.239)]

실무에서는 너가 왜 그렇게 해야했는지만 고려하면 된다

[익명(58.29)]

취업 프로젝트도 다르지 않으려나 나름 고심해서 고안해 낸 해결책인데 삽질일까봐 걱정이군

[백갤러 3(223.39)]

Ddd로 프로젝트 구성하면 애거리거트의 루트에서 도메인 로직을 수행하는 경우가 있음. 이때는 도메인 로직에 필요한 객체들 페치 조인으로 다 땡겨서 씀

[백갤러 4(14.35)]

그럼 연관 엔티티를 포함시켜서 쓰겠네. 외래키 제약조건은 해제하더라도

[백갤러 5(119.204)]

CUD는 그렇게 하고 R은 Querydsl로 함. Fetch join하면 컬럼들 다 땡겨와서 조회 성능 최악이라

[백갤러 4(14.35)]

나도 그렇게 했는데 비즈니스 로직 짜다보니 프로젝션이 능사는 아니더라고. 우후죽순 생겨나는 DTO 관리도 힘들고.

[백갤러 4(14.35)]

혹시 거긴 값 뭐에 담음?