이번 블로그에서는 Spring JPA vs Query DSL vs @Query with JPQL vs @Query with Native Query에 대해서 적어보고자 한다.
각각의 기본적인 장단점을 정리해보고자 한다.
하지만 기본적인 장단점일 뿐이지 상황별 속도나 해당 로직 사용가능 여부는 차이가 나기 마련이다.
따라서 위의 부분은 Trouble Shooting 파트를 통해 정리해보고자 한다.
1. Spring JPA
- Spring에서 제공해주는 ORM이라고 생각하면 간편한다.
- 기본적인 메서드들을 제공해주고 메서드 이름을 설정하여 자신만의 메서드를 만들 수 있다.
장점
- 객체 지향적인 접근 방식으로 데이터베이스와의 상호 작용을 쉽게 구현할 수 있다.
(ORM의 장점이기도 하여, 상이한 장점이라고 보기는 힘들다.)
- CRUD 작업을 간단하게 수행할 수 있는 메서드를 제공
(간단하게 메서드만으로 사용가능하고 직관적인 부분이 있다.)
- 데이터베이스 벤더에 종속되지 않는 추상화 계층을 제공하여 코드의 유연성을 높일 수 있다
(JPARepository를 통해 내가 JPQL을 작성하는 것이 아닌 기존에 작성된 코드를 이용할 수 있다.)
단점
- 복잡한 쿼리를 작성하기에는 한계가 있다.
(예를들어, 조인을 사용하는 쿼리를 작성시 메서드만으로는 작성이 불가능하여 @Query를 통해 JPQL을 작성하거나 Native Query를 작성해야한다. 즉, 복잡한 쿼리에는 한계점이 있고 간단한 CRUD에서는 가볍게 쓰기 용이하다.)
- 동적 쿼리를 작성하기가 어렵고 복잡할 수 있다.
(기본적으로 Spring JPA는 정적쿼리 작성에 최적화되어있다. 하지만 동적 쿼리 작성 예를 들어, 메서드 입력에 name이 null이 아니면 쿼리 where절에 조건을 추가하는 등의 경우에서 코드가 복잡해진다.)
@Query with JPQL 과정 : BooleanExpression, BooleanBuilder등으로 조건절 생성, if등으로 조건절에 들어갈 @Param 생성
- 성능 최적화를 위한 고급 기능이 제한적
(배치 작업, 인덱스 제어 등)
2. Query DSL
- 하나의 프레임워크 형식으로 보통은 JPQQueryFactory를 주입받아 사용가능하다.
- 팩토리를 주입받고 QClass를 생성하고 메서드들을 사용해 쿼리를 작성한다.
장점
- 쿼리의 가독성이 높고 유지 보수에 용이하다.
- 컴파일 시점에 문법 오류를 잡아내서 오류가 줄어든다.
- 동적 쿼리 작성이 용이하다.
(where절에 미리 작성한 BooleanExpression, BooleanBuilder를 넣어주기만 하면 끝이다.)
- 코드 자동 완성을 통해 쿼리 작성시 실수를 줄일 수 있다.
단점
- 추가적인 의존성이 필요하고 Q Class 생성이 필수적
- 초기 학습 비용이 높을 수 있다.
- 일부 복잡한 쿼리나 특정 데이터 베이스 기능에 대한 지원이 제한적이다.
(Delete Join 지원하지 않는다. - 서브쿼리 등으로 해결 가능)
3. @Query with JPQL
- 기본적으로 Spring JPA에서 사용되는 방식이지만 장단점을 추가적으로 정리해 보았다
- 이는 Spring JPA와 연결된다.
장점
- 기존의 JPQL 문법을 그대로 작성할 수 있어 익숙하고 간편
- 복잡한 쿼리를 작성하는데 유연적
- 동적 쿼리를 작성하기가 상대적으로 쉽다.
단점
- 오타 발견 불가능하다.
- 컴파일시 오류 발견 불가능
- 데이터베이스 종류(벤더)에 종속적인 JPQL 문법을 사용한다.
4. @Query with Native Query
- 직접 네이티브 쿼리를 작성하는 경우
장점
- 기존의 SQL 문법을 그대로 사용 가능
- 복잡한 쿼리나 특정 데이터베이스 기능에 대한 지원이 필요한 경우 용이
- 성능 최적화를 위한 특정 데이터 베이스 기능을 활용 가능
단점
- 데이터 베이스 종류에 종속적인 SQL 문법을 사용한다.
- 오타 발생 가능성이 크다.
- 컴파일시 오류를 잡지 못한다.
- 객체 지향적인 접근 방식에서 벗어나기에 객체간의 관계를 다루지 못함.
(Entity와 DB내의 Table은 완전히 동일하지 않음)