ArchiVIEW의 검색 API를 만들어야 했는데 필터가 존재하여 Spring Data JPA를 사용하기에는 경우의 수를 고려하여 쿼리를 만들어야 했다. 상당히 비효율적이라 생각하여 동적 쿼리를 지원하는 JPQL과 Query DSL을 고민하던 중 compile시 타입 체크가 가능하여 runtime시 좀 더 안정성있는 Query DSL을 채택했다.
Query DSL이란?
Query DSL은 정적 타입을 이용하여 SQL 쿼리를 생성하도록 도와주는 프레임워크
Query DSL을 사용하는 이유
1. 정적 타입 체크를 통한 안정성 향상
JPQL은 개발자가 직접 SQL 쿼리문을 작성하여 오타가 발생할 수 있다. 또한, 컴파일 단계에서 오류가 존재하는지 체크할 수 없다는 문제점이 존재한다. Query DSL은 Compile 단계에서 타입 체크를 통해 안정성을 향상시키고 에러를 최소화할 수 있다.
2. 코드 가독성 향상
JPQL에서 동적 쿼리를 작성하면 문자열을 조작하는 방식으로 로직을 구성해야 한다. 예를 들어 유저 조회 기능을 만들 때 userId 문자열이 파라미터에 존재하면 where 조건을 JPQL에 추가하고 JPQL 파라미터도 set 해줘야 하는 번거로움이 존재한다. 이를 Query DSL을 통해 변환한다면 직관적으로 변해 코드의 가독성을 높일 수 있을 것이다.
Query DSL의 동작 원리
Query DSL의 목적은 JPQL의 생성이다.
JPQL의 동작 원리
JPQL의 동작 원리
Query DSL 동작 원리
Query DSL 동작 원리
Query DSL은 JPQL을 생성할 수 있도록 데이터(Entity)를 설정하여 전달해야 한다.
하지만, Entity는 JPA 프레임워크에서 지원하는 모듈로 쿼리 생성에 특화된 Query DSL 프레임워크와는 분리되어 있다.
Entity를 사용한다면 JPA 프레임워크에 종속되어 버릴 것이고 이를 방지하고자 Query DSL은 QClass를 사용한다.
QClass란?
Entity의 메타 정보를 담고 있는 Class로 Query DSL이 타입 안정성을 보장한 쿼리를 작성할 수 있도록 해준다.
Entity의 클래스와 대응되고 속성을 가지고 있다.
직접 참조가 가능하여 컴파일 시점에서의 오류를 확인하고 IDE의 자동 완성 기능을 지원해준다.
QClass는 컴파일 단계에서 Entity를 기반으로 생성되는데 JPA_APT(JPAAnnotationProcessTool)가 @Entity와 같은 특정 어노테이션을 찾아 해당 클래스를 분석하고 만드는 방식이다.
추후 포스팅을 통해서 Query DSL을 ArchiVIEW 프로젝트에 적용해보며 실습하는 시간을 가져보도록 하겠다.
