JpaRepository를 상속하지 않는다.
회사 코드를 보다가 Repository 코드를 보았는데 신기했다.
JpaRepository를 상속하지 않고,PagingAndSortingRepository을 구현한 인터페이스? 그리고 QuerydlsPredicateExecutor를 사용했다.
보고 왜일까?? 의문이 들어 회사에서 아직 업무가 없을때라서 한번 찾아보았다.
불필요한 메서드들
JpaRepository를 사용하여 자동완성?? 기능같은걸 사용하다보면
정말 다양한 메서드를 자동으로 제공한다.
즉 사용하지 않는 메서드들이 너무 많다. 내가 프로젝트했을 경우도 위 이미지에서 사용하지 않은게 아마 2/3?? 일때도 있다.
이외에도 테스트할때도 fake 객체를 만들어서 한다고 한들 repository 인터페이스의 메서드들을 모두 오버라이딩해야한다.
즉 불필요한 부분들이 존재하는 것이다.
그래서 어떻게 하는데?
앞서 이야기했다 싶이 JpaRepository의 부모 인터페이스??를 구현한다.
그래서 나의 경우 간단하게 이렇게만 구현해보았다.
interface TJpaRepository<T, R> : ListPagingAndSortingRepository<T, R>
, QuerydslPredicateExecutor<T>
interface TPersonRepository : TJpaRepository<Person, Long>이렇게만 구현하였더니
아까보다 확실히 자동으로 완성되는 메서드가 줄어들었다.
만약 이외의 메서드가 필요하다면 이렇게 추가하면 된다(마치 jpaRepository 구현했을때 필요한 메서드를 생성했듯이)
interface TPersonRepository : TJpaRepository<Person, Long> {
fun findById(id: Long): Optional<Person>
}
근데 저 QuerydslPredicateExecutor은 뭐니?
이걸 사실 따로 분리해서 블로그를 쓸가 하다가,,, 내용이 길지 않을 거같아서 함께 정리해본다.
나도 회사에서 처음본 인터페이스?? 였다. 그래서 이게 뭐지 싶어서 찾아봤었다.
Querydsl은 무엇인지 알것이다.
나의경우 Querydsl를 사용할때 CustomRepository를 상속해서 JpaQueryFactory를 사용하여 구성하였다.
QuerydslPredicateExecutor은 약간 편리한 Querydsl기능제공의 느낌이다.
fun test(name: String) {
tPersonRepository.findAll(
BooleanBuilder()
.apply{
QPerson.person.name.eq(name)
}
)
}
이런느낌으로 Predicate를 파라미터로 이용하여 where 쿼리를 만든다. (BooleanBuilder가 null이면 where조건절은 나가지 않는다)
다만 이방식은 조인이 불가능하다. 거기다가 QPerson과 같이 QueryDsl에 의존해야한다.
그러나 우리 팀의 코드를 보면 QueryDsl이 대부분 findAll과 같이 약간의 검색조건과 함께 사용된다.
즉 저런 편리한 기능만이 필요하기 때문에 QuerydlsPredicateExecutor를 사용한 것같다.
간단하게 정리해보았다.
확실히 회사코드보면 조금씩 배우는게 점점 많은 것같다. 굿!