QueryDsl 사용법 (QUERYDSL이란 무엇인가? )

QueryDSL이란?

Querydsl은 광범위한 Java 프레임워크로, SQL과 유사한 구문에서 타입 세이프 쿼리를 생성할 수 있다.

 

현재 JPA, JDO, SQL, 자바 컬렉션, RDF, 루세, 동면 검색, 몽고 DB 등 별도 모듈을 활용해 다양한 백엔드를 폭넓게 지원한다.

 

이 게시물에서 나는 Querydsl의 JPA에 대한 지원과, JPA가 제공하는 이미 풍부한 기능 세트를 확장하는데 어떻게 사용될 수 있는지에 초점을 맞출 것이다.

 

QueryDSL을 선택해야 하는 이유

Querydsl에 대한 대안이 존재하지만, 내가 일상 작업에서 Querydsl을 계속 사용하는 몇 가지 이유는 적응의 단순성, 대량의 리포지토리 방법을 훨씬 더 간단한 하위 집합으로 통합하는 능력(아래 코드 예에서 확인할 것), 그리고 그것이 제공하는 형식 안전성이다.

 

Querydsl을 선택한 내 개인적인 이유 외에도, 창작자들은 또한 다음과 같은 요점을 자랑한다.

– IDE(Integrated Development Environment)에서 코드 완료—모든 속성, 방법 및 작업을 좋아하는 Java IDE에서 확장할 수 있음

– 구문론적으로 잘못된 쿼리가 거의 허용되지 않음(모든 수준에서 유형 안전)

– 도메인 유형 및 속성을 안전하게 참조할 수 있음(관련 문자열 없음)

– 도메인 유형의 변경 사항을 리팩터링하는 데 더 효과적임

– 증분 질의 정의가 용이함

이제 Querydsl의 장점을 알게 되었으니, 프로젝트에서 Querydsl을 사용하는 방법을 보여주는 지침과 코드 예를 들어보자.

기존 프로젝트에서 쿼리를 활성화하는 방법

프로젝트에서 Querydsl을 시작하기 전에 먼저 다음 종속성을 추가하고 아래 플러그인 설정을 사용하도록 프로젝트를 구성하십시오.

 

이 프로세서 플러그인은 엔티티 주석을 사용하여 모든 도메인 유형을 찾고 해당 도메인에서 쿼리 유형을 자동으로 만들어 쿼리를 작성하는 데 사용할 것이다.

이 플러그인이 구성되고 다음 빌드를 수행하면 생성된 모든 쿼리 유형이 "src/main/generated"로 표시됨

 

스프링 데이터를 사용한 동적 쿼리 작성

직원들에 대한 응용프로그램 질의의 많은 부분이 다른 기준에 기초하는 직원 데이터베이스를 고려하십시오.

 

Querydsl을 사용하면 이러한 쿼리를 타입 세이프 방식으로 SQL에 익숙한 구문으로 쉽게 작성할 수 있다.

 

다음은 Querydsl이 당신을 위해 무엇을 할 수 있는지 보여 주는 몇 가지 간단한 예들이다.

 

 

더 자세히 보기

지금까지 Querydsl이 직설적인 Spring Data로 쉽게 수행할 수 없는 일을 해내는 것을 보지 못했다.

 

이제 Querydsl이 무엇인지, 그리고 어떻게 이를 자체 애플리케이션에서 구성할 수 있는지에 대한 기본적인 이해가 되었으므로, 기존의 Spring Data 프로젝트를 살펴보고 Querydsl을 활용하여 리포지토리 및 서비스 계층을 개선하고 단순화하는 방법을 알아보자.


초기 스프링 데이터 저장소

이 사례 적용은 초기에 서로 다른 은행들의 은행 지점 위치를 보유 및 검색하기 위해 설계되었다. 여기서는 시연용으로 사용되며, 이 게시물을 거치면서 강화될 것이다.

 

이 예는 Spring Boot를 사용하여 작성되었으며 초기에는 단순한 Spring Data 저장소였습니다. 은행명, 지점명, 주소, 도시 등 관련 정보가 담긴 단일 모델 브랜치 로케이션(BranchLocation)을 포함하고 있다.

 

이제 BranchLocation 저장소에 집중합시다. Spring Data에 익숙한 사용자는 아래의 코드가 단순한 Spring Data 저장소를 정의하기 때문에 익숙하다는 것을 알게 될 것이다.

 

단순히 이 인터페이스를 만들고 CrudRepository를 확장함으로써, 우리는 실제적인 방법 구현을 쓰지 않고도 사용 가능한 어떤 분야로도 우리의 지점 위치를 검색할 수 있는 저장소를 갖게 되었다.

 

이 응용 프로그램을 실행하면 다음과 같은 리포지토리 검색 방법 중 몇 가지가 사용되는 것을 볼 수 있다.

 

이것은 특히 우리의 실체가 단순하고 데이터 필터링 요구가 매우 제한적일 때 매우 좋은 기능이다.

 

그러나 이 저장소는 우리의 요구와 실체가 증가함에 따라 그것의 약점을 보여주기 시작한다.

 

필터링을 확장해야 할 경우 어떻게 되는가?

이전 예에서 봄 데이터는 우리의 요구에 적합하지만, 우리 기업이 여전히 매우 단순하더라도 검색 요구사항이 변경되면 어떻게 되는가?

 

이 두 필드가 일치하는 두 필드의 조합을 기반으로 지점 위치를 검색할 수 있어야 한다고 상상해 보십시오.

 

이전의 리포지토리 정의를 보면 분명 더 많은 방법을 추가해야 할 겁니다.