• 목차

개요

• Spring Data JPA repo 는 인터페이스만 정의하고 구현체는 스프링이 자동 생성해준다.
• 인터페이스에 대한 구현체를 만들어 사용할 수 있지만 정의한 모든 메소드를 구현해야 한다.
• 만약 인터페이스의 메소드를 직접 구현하여 사용하고 싶다면 어떻게 해야 할까?
  • JPA 를 직접 사용하는 순수 repo 생성 (EntityManager)
  • Spring JDBC Template 사용
  • MyBatis 사용
  • 데이터베이스 커넥션 직접 사용 등등..
  • Querydsl 사용

사용자 정의 인터페이스

public interface memberRepositoryCustom {
    List<Member> findMemberCustom();
}

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

@RequiredArgsConstructor
public class MemberRepositoryImpl implements memberRepositoryCustom {

    private final EntityManager em;

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

• Spring Data JPA 는 이름을 통해 해당 구현 클래스를 인식해서 스프링 빈으로 등록해준다.
• 사용자 정의 구현 클래스의 네이밍 규칙
  • 규칙 1: 리포지토리 인터페이스 이름 + Impl
    • ex) MemberRepositoryImpl
  • 규칙 2: 사용자 정의 인터페이스 이름 + Impl
    • ex) MemberRepositoryCustomImpl

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

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

참고

• 실무에서는 주로 Querydsl 이나 SpringJdbcTemplate 을 함께 사용할 때 사용자 정의 repo 사용
• 항상 사용자 repo 가 필요한 것은 아니다. 그냥 임의의 repo 를 따로 만들어도 된다.
• 예를 들어, MemberQueryRepository 를 인터페이스가 아닌 클래스로 만들고 스프링 빈으로 등록해서 직접 사용하여도 된다. 물론 이 경우 Data JPA 와는 아무런 관계 없이 별도로 동작한다.
• 추가로 사용자 정의 repo 의 사용은 리포지토리를 분리하는 것이 아닌 확장의 개념이다.
• 그러므로 분리가 목적이라면 상속이 아닌 따로 repo 를 생성하는 것이 좋다.
  • 김영한님의 리포지토리 분리 기준은 다음과 같다.
    • 핵심 비지니스 로직이 있는 리포지토리
    • DTO 조회 등을 통한 화면(UI)에 맞춘 로직이 있는 리포지토리