포스트

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 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다