[스프링 데이터 JPA] 사용자 정의 레포지토리를 추가로 구현하는 방법을 알아보자

스프링 데이터 JPA 레포지토리는…

스프링 데이터 JPA 레포지토리는 인터페이스만 정의하고 구현체는 스프링이 자동으로 생성한다. 스프링 데이터 JPA가 제공하는 인터페이스를 직접 구현하면 구현해야 하는 기능이 너무 많다!

그렇다면, 다양한 이유로 인터페이스의 메소드를 직접 구현하고 싶다면 어떻게 해야 할까? 다음과 같은 방법들이 있다.

• JPA 직접 사용 EntityManager
• 스프링 JDBC Template
• MyBatis 사용
• 데이터베이스 커넥션 직접 사용
• Querydsl 사용

 

직접 해결해보자

1. 사용자 정의 인터페이스

2. 사용자 정의 인터페이스 구현 클래스

• 규칙: 상속받을 MemberRepository의 네이밍에 Impl을 붙여서 구현한다. (레포지토리 인터페이스 이름 + Impl)
• 스프링 데이터 JPA가 인식해서 스프링 빈으로 등록한다.

@RequiredArgsConstructor
public class MemberRepositoryImpl implements MemberRepositoryCustom {
    private final EntityManager em;
    
    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery("select m from Member m")
                .getResultList();
    }
}

3. 사용자 정의 인터페이스 상속

public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {
}

 

그렇다면, 위와같이 custom 클래스를 만들어서 구분하는 것이 좋을까?

항상 사용자 정의 레포지토리가 필요한 것은 아니다. 굳이 둘을 구분할 필요는 없다.

• 임의의 레포지토리를 만들어도 된다. 인터페이스가 아닌 클래스로 만들고 스프링 빈으로 등록해서 직접 사용해도 된다.
• 물론 위의 경우 스프링 데이터 JPA와 아무런 관계 없이 별도로 동작한다.
• 쿼리로 동작되는 경우 MemberQueryRepository같은 클래스를 빈으로 등록하여 따로 사용하는 것도 좋은 방법이다.
• 그렇다면 어떤 것으로 구분해야 할까? 이는 팀 컨밴션에 따라 다를 것이다. 고민해보자
  • 커맨드 vs 쿼리
  • 핵심 비즈니스 로직 vs 핵심이 아닌 로직
  • 라이프사이클에 따라 변경되는 로직