[Spring Boot] JPA 동적 쿼리 사용하기

🚀 개요

프로젝트 진행 중

 

관리자 페이지에서 여러 조건으로 기업을 검색해야 하는 API가 필요했다.

 

동적 쿼리를 안 쓰고

 

단순히 if문으로 분기처리해서 일일이 쿼리문을 날리도록 할 수 있겠지만

 

service 랑 repository 단 메서드나 코드가 상당히 늘어나기 때문에 지저분해진다.

 

조건이 4가지여서 repository에 해당 API를 위한 조회 메소드가 16개나 필요했다.

 

혹여나 조건이 추가되면 점점 관리하기도 어려워질 것이다.

 

이러한 단점을 해결하기 위해 JPA 동적 쿼리를 활용하기로 했다.

 

JPA에서 동적 쿼리를 생성하는 방법은 보통 JPQL, Criteria, Specification, QueryDSL 이렇게 4가지가 있다.

 

또다른 방법으론 JPA가 아닌 MyBatis나 검색 기능 자체를 컴포넌트로 빼는 방법도 있다고 하지만

 

난 JPA만 사용하기 때문에 전자의 방법만 기록한다.

 

🚀 동적 쿼리 사용하기

⭐ JPQL

// Repository
public Page<Company> findWithFilters(
        final Pageable pageable,
        final FindCompanyAdminRequest request
) {
    String jpql = "select c from Company c";
    List<String> whereFilter = new ArrayList<>();

    if (StringUtils.hasText(request.getType())) {
        whereFilter.add("c.type = :type");
    }
    if (StringUtils.hasText(request.getCity())) {
        whereFilter.add("c.city = :city");
    }
    if (StringUtils.hasText(request.getDistrict())) {
        whereFilter.add("c.district = :district");
    }
    if (request.getStatus() != null) {
        whereFilter.add("c.status = :status");
    }

    if (!whereFilter.isEmpty()) {
        jpql += " where " + String.join(" and ", whereFilter);
    }

    TypedQuery<Company> query = entityManager.createQuery(jpql, Company.class);

    if (StringUtils.hasText(request.getType())) {
        query.setParameter("type", request.getType());
    }
    if (StringUtils.hasText(request.getCity())) {
        query.setParameter("city", request.getCity());
    }
    if (StringUtils.hasText(request.getDistrict())) {
        query.setParameter("district", request.getDistrict());
    }
    if (request.getStatus() != null) {
        query.setParameter("status", request.getStatus());
    }

    List<Company> companies = query.setFirstResult((int) pageable.getOffset())
            .setMaxResults(pageable.getPageSize())
            .getResultList();

    return new PageImpl<>(companies, pageable, companies.size());
}

// Service
Page<Company> companies = companyRepository.findWithFilters(generatePageDesc(pageNo, LARGE_PAGE_SIZE, criterion), request);

동적 쿼리를 이용하지 않을 때와 비교해서 Repository의 메서드와 Service의 코드가 줄어들었다.

 

하지만 여전히 단점은 존재한다.

 

각 조건에 따라서 if 문을 사용한 방식으로 쿼리를 생성하고 있지만, 문자열을 통해서 하고 있다.

 

문자열을 통해서 쿼리를 만들게 되면 작성한 문자열 쿼리 중 띄어쓰기 혹은 알파벳의 오류가 있을 경우

 

이를 컴파일 단계에서 잡아주지 못한다는 단점이 존재한다.

 

즉, 쿼리를 동적으로 생성하다 보니 개발자가 실수할 수 있는 포인트는 더 늘어났지만

 

쿼리를 실행하기 전까지는 오류를 찾을 수 없다.

 

⭐ Criteria

Criteria는 JPQL을 문자열이 아닌 자바 코드로 작성하도록 도와주는 API다.

 

문법적인 오류를 컴파일 단계에서 잡을 수 있으므로

 

JPQL보다 좀 더 안전하게 동적 쿼리를 생성할 수 있도록 돕는다.

// CompanyRepositoryCustomImpl
public Page<Company> findWithFilters(
        final Pageable pageable,
        final FindCompanyAdminRequest request
) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    CriteriaQuery<Company> cq = cb.createQuery(Company.class);
    Root<Company> root = cq.from(Company.class);
    List<Predicate> predicates = new ArrayList<>();

    if (StringUtils.hasText(request.getType())) {
        predicates.add(cb.equal(root.get("type"), request.getType()));
    }
    if (StringUtils.hasText(request.getCity())) {
        predicates.add(cb.equal(root.get("city"), request.getCity()));
    }
    if (StringUtils.hasText(request.getDistrict())) {
        predicates.add(cb.equal(root.get("district"), request.getDistrict()));
    }
    if (request.getStatus() != null) {
        predicates.add(cb.equal(root.get("status"), request.getStatus()));
    }

    cq.where(cb.and(predicates.toArray(new Predicate[0])));
    cq.select(root);

    List<Company> companies = entityManager.createQuery(cq)
            .setFirstResult((int) pageable.getOffset())
            .setMaxResults(pageable.getPageSize())
            .getResultList();

    return new PageImpl<>(companies, pageable, companies.size());
}

JPQL을 이용해서 동적쿼리를 생성하는 것보다 훨씬 간단해졌다.

 

또한 문자열을 통해서 쿼리를 생성하지 않아 개발자가 실수할 수 있는 포인트도 줄었다.

 

이처럼 JPA에서 제공하는 Critera를 사용하게 되면 동적 쿼리를 더 간단하고 안전하게 생성할 수 있다는 장점이 있다.

하지만 쿼리를 생성하기 위한 코드가 어려워졌다.

 

그리고 생성해야 하는 Predicate가 많아진다면 관리하기 어려워지고

 

직관적으로 이해하기 힘들다는 단점이 발생한다.

 

⭐ Specification

Specification은 Spring Data JPA에서 제공하는 API로, 복잡한 쿼리를 유연하게 생성할 수 있게 해준다.

 

JPA는 Criteria의 사용성을 높이기 위해서 Specification으로 해결법을 제공하고 있다.

 

Specification을 사용하기 위해서는 Repository에서 JpaSpecificationExecutor을 상속 받아야 한다.

// Repository
public interface CompanyRepository extends JpaRepository<Company, Long>, JpaSpecificationExecutor<Company> {
	
    Page<Company> findWithFilters(final Specification<Company> spec, final Pageable pageable);
}

// Service
Page<Company> companies = companyRepository.findWithFilters(CompanySpec.findWith(request), generatePageDesc(pageNo, LARGE_PAGE_SIZE, criterion));

기존의 JPA와 달라진 점은 Specification<Company> spec 을 받아서 사용하고 있다.

 

Specification을 이용해서 동적 쿼리를 구현할 수 있게 되었다.

// CompanySpec
public static Specification<Company> findWith(final FindCompanyAdminRequest request) {
    return (root, query, cb) -> {
        List<Predicate> predicates = new ArrayList<>();

        if (request.getType() != null && !request.getType().isEmpty()) {
            predicates.add(cb.equal(root.get("type"), request.getType()));
        }
        if (request.getCity() != null && !request.getCity().isEmpty()) {
            predicates.add(cb.equal(root.get("city"), request.getCity()));
        }
        if (request.getDistrict() != null && !request.getDistrict().isEmpty()) {
            predicates.add(cb.equal(root.get("district"), request.getDistrict()));
        }
        if (request.getStatus() != null) {
            predicates.add(cb.equal(root.get("status"), request.getStatus()));
        }

        return cb.and(predicates.toArray(new Predicate[0]));
    };
}

CompanySpec 클래스를 만들고 정적 메서드를 사용했다.

 

Criteria만 활용하는 것보다 코드가 훨씬 간단해진 모습을 볼 수 있다.

 

CriteriaQuery 작성을 위한 준비 코드를 작성하지 않아도 되고,

 

JPA를 활용한 쿼리를 사용할 수 있으니 이전보다 보기 좋고 쉬운 코드가 완성되었다.

 

하지만 여전히 Criteria를 통한 동적 쿼리 생성 방식은 복잡하고 장황하다.

 

무엇보다 코드의 형태가 SQL과는 거리가 있다.

 

⭐ QueryDSL

QueryDSL은 타입 안전성을 제공하고, 복잡한 쿼리를 직관적으로 작성할 수 있게 해준다.

 

그리고 Criteria의 복잡함을 개선할 수 있는 JPQL 빌더 역할을 하는 오픈 소스 프로젝트다.

 

문자열이 아닌 자바 코드로 쿼리를 생성하는 것임에도 불구하고,

 

더 쉽고 간결하며 형태도 SQL과 비슷하게 개발할 수 있다는 것이 QueryDSL의 장점이다.

// CompanyRepositoryCustomImpl
public Optional<Page<Company>> findWithFilters(
            final Pageable pageable,
            final FindCompanyAdminRequest request
    ) {
        List<Company> companies = jpaQueryFactory
                .selectFrom(company)
                .where(
                        toContainsType(request.type()),
                        toContainsCity(request.city()),
                        toContainsDistrict(request.district()),
                        eqCompanyStatus(CompanyStatus.valueOf(request.companyStatus()))
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();


        return Optional.of(new PageImpl<>(companies, pageable, companies.size()));
    }

    private BooleanExpression toContainsType(final String type) {
        if (!StringUtils.hasText(type)) {
            return null;
        }
        return company.type.contains(type);
    }

    private BooleanExpression toContainsCity(final String city) {
        if (!StringUtils.hasText(city)) {
            return null;
        }
        return company.city.contains(city);
    }

    private BooleanExpression toContainsDistrict(final String district) {
        if (!StringUtils.hasText(district)) {
            return null;
        }
        return company.district.contains(district);
    }

    private BooleanExpression eqCompanyStatus(final CompanyStatus companyStatus) {
        if (companyStatus == null) {
            return null;
        }
        return company.companyStatus.eq(companyStatus);
    }

Criteria와 비교했을 때 불필요한 Predicate를 생성하는 과정이 없어 더 간결하고 가독성이 좋아졌다.

 

그리고 더 SQL스럽게 코드가 작성되었다.

 

Where 문에 어떤 조건들이 들어가는지 확인할 수 있어 훨씬 가독성이 좋아졌다.

 

이처럼 QueryDSL 을 통해서 동적 쿼리를 생성하는 방식이 Specification에 비해서 가독성이 더 좋다.

 

하지만 QueryDSL 에도 단점이 없는 것은 아니다.

 

Criteria보다는 쉽지만, SQL 작성을 위해서 러닝 커브가 필요하다.

 

또한 Q Class에 의존하여 쿼리를 생성하는 것도 단점이다.

 

Q Class를 생성하는 방법이

 

어떤 버전과 빌드 방식을 사용하는가에 따라서 신경을 쓰고 다르게 설정해 주어야 하기 때문이다.

 

처음에 Q 클래스 import가 안 되어서 많이 당황했고 방법을 찾느라 고생했다 ㅠ.

 

🚀 결론

지금까지 여러 조건으로 조회하는 기능을 개발하기 위해

 

JPA에서 선택할 수 있는 대안들에 대해서 기록했다.

 

초반에는 Service 레이어에서 if 문을 통해서 각 쿼리를 실행하는 것이 직관적이고 코드를 작성하기 편했다.

 

하지만 검색에 대한 조건이 점차 늘어남에 따라서 동적 쿼리의 필요성을 느꼈습니다.

 

최종적으로 Querydsl을 활용해서 동적 쿼리를 생성하는 방법을 선택했다.

 

그 이유는 SQL 문을 생성함에 있어서 컴파일 타임에 오류를 잡아줄 수 있어야 했고,

 

무엇보다 가독성이 중요하다고 느꼈기 때문입니다.

 

- 끝 -