[개발]🤦🏻‍♀️고민하기 - Querydsl 사용 시 클래스 구조(repository, service)

🌦️기존상황

기존 프로젝트 : querydsl을 사용할 때의 구조

• 간단하게 구조도를 그려봤다.
• 그리고 보니 querydsl을 사용한 메서드를 기준으로 보면 repository와 전혀 관계를 맺고 있지 않다. 
• querydsl을 사용하니 JPA메소드도 사용하지 않기 때문이다.
• service에다가 querydsl을 적어놓은 이유는 service 단에 늘 함수들을 구성해 놓았기 때문이다!! 

---

⛅과정

• 같은 백엔드 팀원에게 해당 구조에 대해 문제점을 제기받았다. 
• 처음에는 굳이..? 싶었다. 괜히 복잡하게 클래스만 늘어나는 거 같아서 의문스러웠다.
• 그런데 알아보니 나처럼 service단에서 querydsl을 쓰는 경우는 거의 없는 거 같았다.^^ 더 나은 코드를 위해서라면 더 이상 고민할 이유가 없었다.

---

☀️해결

변경해본 클래스 구조

• schoolRepository가 JPARepository, SchoolRepositoryCustom을 상속받고, 이에 대한 구현체인 SchoolRepositoryImpl을 생성한다.
• 이 방법을 보편적으로 사용하고, 같은 팀원도 이 방법을 사용하고 있기 때문에 이 방식을 선택했다. 
• 원래는 SchoolRepository 하나로 interface - impl 구조를 가져갈 수 없을까 했는데 그러면 JPA에서 재공 하는 메서드까지 싹 다 구현해야 하는 거 같았다.

Repository란
실제로 DB에 접근하여 연결다리 역할을 하는 기능을 한다. 한마디로 기존 DAO기능을 하는 부분이다.

기능구현에 급급하다보니 뭐가 뭔지 제대로 생각하고 구현하지 못했는데 각 정의, 기능들을 생각해 보니 레포쪽에 있는 게 맞다는 생각이 들었다.