Custom Repository

 

스프링 데이터 JPA는 실제 인터페이스만 제공하고 구현체는 스프링이 자동 생성해준다. 

 

그런데  EntityManager를 직접 사용해야 하거나 JDBC Template, MyBatis 등등 다른 기능을 사용하려면 어떻게 해야 할까?

 

스프링 데이터 JPA를 포기하고 별도의 리포지토리를 만들어서 사용해야 할까?

 

이럴 땐 다음과 같이 사용해보자.

 

우선 별도의 인터페이스로 커스텀하고자 하는 기능을 만들자.

public interface MemberCustomRepository {

    List<Member> findMemberCustom();
}

 

이후 해당 인터페이스를 상속받는 클래스를 하나 정의하자.

 

@RequiredArgsConstructor
public class MemberCustom implements MemberCustomRepository{

    private final EntityManager em;

    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery("select m from Member m", Member.class).getResultList();
    }
}

 

이제 스프링 데이터 JPA 인터페이스에 커스텀한 인터페이스를 넣어주자.

public interface MemberRepository extends JpaRepository<Member, Long>, MemberCustomRepository

 

스프링 데이터 JPA는 해당 인터페이스의 구현체를 찾아 넣어준다. 따라서 별도의 설정도 필요가 없다.

 

그런데 이 경우 테스트는 실패한다. 

 

@RequiredArgsConstructor
public class MemberCustom implements MemberCustomRepository{

    private final EntityManager em;

    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery("select m from Member m", Member.class).getResultList();
    }
}

 

그 이유는 구현체에서 규약이 존재하기 때문이다. 

 

실제 사용되는 MemberRepository 인터페이스 네이밍에서 Impl까지 붙인 MemberRepositoryImpl로 네이밍을 해야 한다.

 

이를 구현체의 이름을 바꿀 수 있지만 관습을 최대한 따라주자. 이는 나 말고 다른 팀원을 위해서라도 기본을 지키는 것도 유지보수에 많은 도움이 될 수 있다.

 

최대한 애플리케이션 코드단에서 처리하려 해도 매우 무겁고 복잡한 쿼리가 필요한 경우 실제 스프링 데이터 JPA의 쿼리 메서드와 @Query로도 안 되는 경우가 존재한다. 

 

비즈니스가 크지 않다면 한 곳에 모아서 복잡한 쿼리나 간단한 쿼리를 뭉치는 것도 좋을 것 같지만 서비스가 좀 크다면

커스텀을 사용해 하나의 인터페이스로 합치는 것보다 실제로 분리하여 사용하는 것도 좋을 것 같다. 

 

나는 뭐.. 동적 쿼리랑 정적 쿼리로 나누긴 했다.  또 간단 화면 데이터랑 실제 비즈니스 로직이랑 나누었던 것 같다.

 

그럼 우리는 이 사용자 정의 리포지토리를 구현해 기존 사용하던 스프링 데이터 JPA 인터페이스와 합쳐서 사용할 수 있다는 점

 

이를 기억하고 있다가 적절한 상황이 온다면 잘 사용해보자!