내가 느낀 QueryDsl의 장단점과 후기

텀블벅 사전 과제 프로젝트 작업 중 QueryDsl이라는 것을 접하게 되었다.

 

jpa에서 Repository를 생성할 때, CrudRepository<Entity, Type> 혹은 JpaRepository<Entity, Type> implements 받는다.

객체로 DB를 다루는 JPA 특성상 Entity로 지정된 Class로만 CRUD가 가능한데

내가 하고 싶었던 것은 지정된 Entity가 아닌 DTO로 반환받는 것이었다.

DTO로 반환받는 방법 중 그 당시 생각한 방법을 간략하게 나열해보자면 아래와 같다.

 

1. Entity로 반환받은 뒤 반환된 값으로 DTO를 생성한다.

2. Repository가 아닌 Query문을 작성한다.

3. @Query 어노테이션을 사용한다.

 

1번은 불필요한 데이터를 호출해야 한다는 점

2번은 Query문을 작성하여 적용해도 됐지만 좀 더 JPA에서 제공하는 기능을 사용하고 싶었고

sql 파일 특성상 오타를 잡기 힘들다는 점에서 선택하지 않았다.

 

결국, 3번째 방법을 선택하여 여러 가지 방식으로 도전해봤지만 지정한 Entity 이외에 다른 class로 반환받을 방법을 찾을 수가 없었다.

 

그렇게 이틀 정도 삽질과 검색을 하며 찾은 결과 QueryDsl을 접할 수 있었고, 이것이야말로 내가 찾던 것임을 확신할 수 있었다.

 

QueryDsl을 처음 접했을 때 Dependency만 추가하면 되는 것으로 생각했으나 추가적인 build 방법으로 인해 어렵다는 느낌이 들었다.

 

하지만 QueryDsl을 사용하면 내가 원하는 대로 DTO를 반환받을 수 있고

QClass로 지정된 Entity의 변수를 entity.getParameter 이런 식으로 호출되었기 때문에 변수명을 틀려서 에러가 날 일이 없었다.

거기다 pageable class를 통한 페이징 처리도 가능하다.

 

이러한 장점이 있다고 느낀 QueryDsl에 대한 자세한 사용법은 다음 글에서 다루도록 하겠다.