QueryDSL 도입

[morenow98]

관련 PR: #52

QureyDSL 도입

• 북마크 표시를 하려면 memberId의 유무에 따라 데이터베이스에 다른 쿼리가 실행된다.
• 기존에 examId의 유무에 따라 다른 쿼리가 실행되어 메소드가 2개 존재했었으므로, 아래와 같이 기존 방식대로 한다면 이제 메소드는 4개가 된다.
  @Query(value = "select * from problem where subject_id = :subjectId order by rand() limit :count", nativeQuery = true) List<Problem> findRandomBySubjectId(Long subjectId, int count);
  • 어노테이션을 활용한 방식은 정해진 정적 쿼리만 가능하다.
• 따라서 동적쿼리를 다룰 다른 방식들이 필요했다. 3개의 후보가 있었다.

1. JPA Specification

• JPA 자체에서 제공하는 JpaSpecificationExecutor를 상속받아 활용하는 방법이다. JPA의 Criteria를 내부적으로 사용하게 되는데, 코드 자체가 너무 알아보기 힘들고, join 등 복잡한 쿼리가 만들어지면 코드를 알아보기 너무 힘들다.
• https://www.inflearn.com/community/questions/16685/specification-%EB%8C%80%EB%B9%84-querydsl%EC%9D%98-%EC%9E%A5%EC%A0%90%EC%9D%B4-%EC%96%B4%EB%96%A4%EA%B2%83%EC%9D%B4-%EC%9E%88%EC%9D%84%EA%B9%8C%EC%9A%94

2. JPQL 혹은 JDBC template

• Entity Manager 등을 통해 문자열로 쿼리를 직접 만들어서 실행하는 방법이다.
• 직접 문자열만을 통해 쿼리를 생성하기 때문에 컴파일 시간에 오류를 잡아내기도 힘들고 관리할 동적으로 관리할 때 문자열들이 많아져서 코드 자체의 관리도 힘들다.

3. QueryDSL

• 외부 라이브러리를 통해 쿼리의 작성을 더 편하게 해준다. 1번 방법과 같지만 훨씬 직관적이다.
• 외부 모듈에 의존한다는 단점이 있다.

외부 모듈에 의존한다는 단점을 제외하면 코드의 관리와 직관성 면에서 우수한 3번을 택했다.
하지만, 쿼리 성능을 위해 Discussion이 필요하다.