반려 식물 단건 히스토리 조회 시, 필터링 기능을 구현할 때 Querydsl 도입에 관하여

[rawfishthelgh]

현재 반려 식물 단건 히스토리 조회 url는 다음과 같습니다.
/history?petPlantId=1&page=0&size=20&filter=”lastwaterDate,flowerpot…”

여기서, filter의 value는 0개에서 최대 6개까지 늘어날 수 있습니다.
filter="lastwaterDate,flowerpot,location,waterCycle,light,wind,lastWaterDate" 와 같은 형태로요

이 경우 조회하기 위해 생기는 Sql이
select * from history where history.history_category_id in (?,?,?...)
과 같은 형태로 몇 개의 필터 값이 들어오는지에 따라 계속 변하게 됩니다.
그렇다면 우리는 이를 지금 해결하기 위해서, 어마무시한 분기문을 작성해야 할 것입니다.(대충 짐작만 해도 2~30개...)

따라서, 동적 쿼리를 쉽게 해결할 수 있는 프레임워크를 도입하는 것이 러닝커브가 있더라도 적합할 수 있다는 생각이 들어,
QueryDsl을 통해 문제를 해결하는 방향을 제안하고 싶습니다.

[Choi-JJunho]

동의합니다!
향후 리팩터링에 소요되는 리소스를 고려해봐도 동적쿼리를 쉽게 작성할 수 있도록 도와주는 라이브러리를 사용하는것이 더욱 효율적이라는 생각이 드네요

[Kim0914]

좋아요 !

현재 쿼리를 작성하는 방식으로 해당 기능을 개발할 시 꽤 많은 분기문이 발생할 것 같네요 !
적절한 상황에서 필요한 기술을 도입하는 것이기 때문에 매우 찬성합니다 ㅎㅎ