QueryDSL을 도입한 이유

QueryDSL을 도입한 이유

• JPQL(Java Persistence Query Language)
  • JPA에서 제공하는 메소드 호출만으로 섬세한 쿼리작성이 어렵다는 문제로 탄생된 것으로 테이블을 대상으로 쿼리하는 것이 아닌 엔터티 객체를 대성으로 쿼리한다.
• QueryDSL
  • JPQL을 java코드로 작성하게 해주는 JPQL Builder이다. (=쉽게 말해, JPQL을 java코드로 작성가능하다.)
  • 장점
    • 코딩 과정에서 문법에러를 미리 알 수 있으며, 검색을 위한 유동적인 쿼리를 작성할 수 있는 장점을 가지고 있다.
  • 단점
    • JPA 1차 캐시사용이 불가능하다.
      • JPA를 통해 select하게되면, 영속성 컨텍스트 1차 캐시에 데이터가 저장되는데,
      • QueryDSL은 이를 무시하고 DB에서 직접적으로 조회해온다.
      • 여기서 발생하는 문제는 아래와 같다.
        • 예를 들어서 모든 회원의 이름이 john이고 JPA로 모든 회원을 한번 조회했다고 했을 때, 영속성 컨텍스트 1차 캐시에 모든 회원의 이름이 john으로 저장되어 있을 것이다. 이 상황에서 QueryDsl로 회원의 이름을 전부 simpson으로 바꿔도 JPA로 조회를 한다면 JPA 1차 캐시에 존재하는 회원(이름이 john)의 데이터를 반환하기 때문에 모든 회원의 이름이 john으로 나올 것이다.

petree에서 사용한 QueryDSL

• 이유1) '로그인한 사용자의 주소를 기반으로 구한 위도,경도'와 '서비스 내에 있는 모든 브리더의 주소를 기반으로 구한 위도,경도'를 기반으로, 로그인한 사용자와 모든 브리더간의 거리를 구할 수 있게 되었다. 이를 토대로, 로그인한 사용자를 기준으로 브리더를 거리순으로 정렬하고자 하였는데 해당 기능은 jpq가 제공해주는 일반 메소드로는 해결이 불가능하였다. 따라서, querydsl을 도입하였다.
• 이유2) 검색을 위한 유동적인 쿼리를 작성하기 위해서이다. '브리더 모아보기'페이지에서 인증유무에 따른 브리더 조회, 브리더 이름, 브리더의 주력견종을 기반으로 조회등을 검색 + 페이징처리하는 부분을 JPQL을 이용한다면, 각 상황별로 쿼리문을 작성해야했을 것이다. 이를 유동적으로 처리하고자 QueryDSL을 도입하였다.
• 참조블로그
  • https://dev-coco.tistory.com/141
  • https://studio108.tistory.com/26
  • https://velog.io/@cws0718/Spring-JPA-QueryDsl%EC%9D%B4%EB%9E%80