작성
·
4.8K
·
수정됨
1
안녕하세요. 먼저 질 좋은 강의 덕분에 새로운 기술을 배우고 서비스에 적용 시키며 보람을 느끼고 있습니다. 감사합니다.
다름이 아니라 현재 Spring JPA +QueryDSL 로 개발을 하던 도중 소스를 다시 훑어 보니 문득 의아한 생각이 들었습니다.
제가 개발 해 놓은 소스를 보다 보니 Query 시 객체 탐색을 통한 구현이 거의 이루지지 않았더군요. 그래서 왜 이렇게 개발을 했나 하고 생각 해보니
각 client(ex:브라우저) 의 요구사항에 맞는 데이터를 각 Entity에서 조회를 해야하나 사용하지 않은 모든 컬럼의 데이터를 조회 하는 것에 대해서는 비효율적일 수 있다. (테이블 내 컬럼이 많아질수록... 컬럼 내 타입 사이즈가 커질수록...)
이에 Entity를 자체를 조회가 아닌 QueryDSL의 on 절 및 Projection을 통해 성능 향상을 이룰 수 있다.
그러다 보니 기능 동작 관점에선 각 Entity간 연관관계를 통해 탐색을 거의 하지 않게 된다.
결국 이런 결론에 도달하게 되었는데요. 이러다 보니 초기 강의를 들으면서 적용 했던 소스와는 달리 현재는 대부분 객체간의 연관관계를 설정하더라도 객체 탐색을 쓰지 않게 되고 있습니다.
그 외에도 개인적인 생각이지만 객체 탐색을 통해 실무에서 주니어분들이 의도치 않은 성능 저하를 (n : 1 등) 일으킬 수 있어서 지양하는 대신, 정말 작은 규모의 테이블 하나만 조회 할 때 빼고는 사용을 안하는 방향으로 개발을 진행하고 있는데 이게 jpa의 기능을 절반 떼어버리는 듯한 느낌이 들어서 잘 이해한건지 불안불안 합니다.
그래서 혹시 실무에서는 객체 탐색을 하는 경우가 있으신지 있다면 어느 케이스일 때 사용하는지 궁금합니다.
그리고 객체 탐색 시 필요한 컬럼만 조회 하는 기능이... 있을까요?? 있다면 이런 질문을 드리지 않았을 거 같긴한데... 찾아 봐도 잘 안나오더군요ㅠ
답변 1
1
안녕하세요. 오래된개발자님
이 부분에서는 다양한 트레이드 오프가 있습니다.
연관관계가 있으면 fetch join을 사용해서 코드상에서 매우 편리하게 성능 최적화를 해서 데이터를 조회할 수 있지만, 단점으로는 DB에서 select 되는 필드들이 많이 늘어나게 되지요.
그래서 단건 조회 같은 경우에는 이 부분이 많이 편리하지만, 리스트 조회 같은 경우에는 DTO에 맞추어서 조회를 많이 하게 됩니다.
성능이 중요한가, 아니면 코드의 단순함과 재사용성이 더 중요한가에 따라서 선택이 필요한 영역이라 생각합니다.
저도 실무에서는 DTO를 상당히 많이 만들어서 사용하는 편입니다.
특히 조회나 제공해야 하는 API가 많은 경우에는 아무래도 DTO가 많이 사용됩니다.
주로 데이터를 저장하고 관리해야 하는 핵심 비즈니스 로직 같은 경우에는 엔티티와 연관관계가 많이 사용됩니다.
감사합니다.
자칫 강의와 벗어난 질문일 수도 있는데 실무 상황과 함께 설명해주셔서 매우 감사합니다!
(늘 그렇지만 새로운 걸 배워도 제대로 활용하고 있는지에 대한 불안감 때문에 질문을 드리게 되네요 ㅠ)