Repository 생성 문의드립니다.

Question

영한님 안녕하세요.  이제 기본편 학습이 끝나가고 있고, 곧 실전편 학습을 시작할 수 있을 거 같습니다. ㅎ 또 문의드릴 내용을 하나 들고 왔는데요. 쿼리 실행을 할 수 있는 방법들이 JPA 에는 생각보다 다양한 것 같습니다. Spring Data JPA 환경에서 반복사용할만한 Repository 기본 틀을 한번 만들어 보고 있는데요. 아래와 같은 구성으로 틀을 만들어 놓으면 중소형 프로젝트를 할 때 큰 무리가 없어 보일 거 같은데 좀 개선이 필요할만한 부분이 있다면 조언 부탁드릴께요. ------------------------------------------------------------------------- Book 이라는 도메인이 있을 경우 1) interface BookCustomRepository 2) interface BookRepository extends JpaRepository, BookCustomRepository 3) class BookCustomRepository extends QuerydslRepositorySupport  implements BookCustomRepository repository 패키지 내에 위 3가지 구조로 와꾸를 만든 뒤 2번에서는 "쿼리 메소드" 기능과 @Query 활용 3번에서는 JPQL 과 QueryDSL 활용한 구현체 작성 ------------------------------------------------------------------------- 아직 기본편과 책만으로 학습중이라 내공이 부족한데 실무 관점에서 몇마디 조언해 주시면 감사하겠습니다. 그리고 근처 타팀에서 JPA 프로젝트하는 곳을 살짝 들여다 봤는데 Repository 구현체는 전혀없고 Service Layer 에서 QueryDsl 을 작성하고 있던데 이러한 개발 형태는 어떨 지 함께 의견 부탁드릴께요.

김영한 · Answer

안녕하세요. 아리마님^^ 보통 실무에서 말씀하신데로 많이 진행합니다. 활용편에서도 설명하는 내용이지만, 미리 설명을 드릴께요^^ 핵심 비즈니스 로직과 관련된 기능들은 위에서 설명하신 내용(1,2,3)에 많이 포함하면 됩니다. 반면에 특정 화면이나 조회 API에 의존도가 매우 높은 기능을 조회하는 리포지토리는 BookQueryRepository 처럼 별도의 리포지토리로 분리하는 것도 좋은 방법입니다. (물론 프로젝트가 어느정도 규모가 있을 때 분리하는게 좋습니다. 프로젝트가 작고 단순하다면 하나로 처리하는게 더 나은 선택일 수 있습니다.) 핵심 비즈니스 로직을 위한 변경사항과, 특정 화면등을 위해 처리되는 변경사항의 라이프사이클이 다르기 때문이지요. 그리고 나중에 기능이 많아지면, 정말 중요한 리포지토리 메서드와 그렇지 않은 단순 조회성 리포지토리 메서드를 구분해두어야 유지보수하기 좋습니다^^(이건 프로젝트 상황에 따라 다르겠네요) 그리고  Service Layer 에서 QueryDsl 을 작성하고 있던데 -> 이 부분은 논란의 여지가 있을 수 있지만, QueryDSL은 데이터 접근 계층의 기술이기 때문에, 가급적 리포지토리 계층에서 사용하는게 맞다고 생각합니다. 물론 이 부분도 실용적인 관점에서 서비스 계층에서 사용할 수 있기는 하지만... 향후 다른 기술로 변경할 때 서비스 계층을 전부 수정해야 하는 큰 단점이 있습니다. 감사합니다^^!