Querydsl을 사용하는 이유와 기본 패턴
Querydsl이 필요한 순간
조회 조건이 조금만 복잡해져도 메서드 이름 쿼리나 문자열 JPQL은 금방 읽기 어려워진다. Querydsl은 이 문제를 “타입 안전한 쿼리 빌더”로 해결한다.
장점
- 컴파일 타임에 필드 변경 오류를 발견할 수 있다.
- IDE 자동완성이 잘 된다.
- 조건 조합이 명확하다.
- Repository 구현을 읽기 좋게 유지할 수 있다.
기본 구조
Querydsl은 엔티티 기반으로 생성된 Q타입을 사용한다.
1
QOrder order = QOrder.order;
이후 JPAQueryFactory로 조건을 조합한다.
1
2
3
4
return queryFactory
.selectFrom(order)
.where(order.status.eq(OrderStatus.PAID))
.fetch();
동적 조건 패턴
가장 많이 쓰는 방식은 BooleanExpression을 메서드로 분리하는 것이다.
1
2
3
private BooleanExpression eqKeyword(String keyword) {
return hasText(keyword) ? order.name.contains(keyword) : null;
}
where(...)는 null 조건을 무시하므로 조합이 편하다.
언제 특히 유용한가
- 검색 조건이 3개 이상으로 늘어날 때
- 조인과 정렬이 복잡할 때
- Repository 메서드 이름이 과도하게 길어질 때
- 커스텀 조회 전용 Repository가 필요할 때
주의할 점
- Querydsl을 도입해도 인덱스 전략이 해결되는 것은 아니다.
- 복잡한 조회는 결국 실행 계획을 확인해야 한다.
- 카운트 쿼리와 본문 쿼리를 분리해야 할 때가 많다.
정리
Querydsl은 “쿼리를 멋지게 쓰는 기술”이 아니라, 복잡한 조회 요구사항을 코드로 안전하게 표현하기 위한 도구다. 조건 조합이 많아지는 시점부터는 충분히 투자할 가치가 있다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.
댓글
아직 댓글이 없습니다