https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#repositories.definition
Spring Data JDBC - Reference Documentation
Example 10. Repository definitions using domain classes with annotations interface PersonRepository extends Repository { … } @Entity class Person { … } interface UserRepository extends Repository { … } @Document class User { … } PersonRepository re
docs.spring.io
리포지토리 인터페이스를 정의하기 위해, 첫째로 도메인 클래스-특정 리포지토리 인터페이스를 정의해야 한다. 인터페이스는 Repository를 상속받아야만 하고, 도메인클래스와 ID타입이 타입지정되어야 한다. 도메인 타입에 대한 CRUD 메소드들을 노출시키길 원한다면, CrudRepository를 상속받을 수 있고, 아니면 Repository대신 다른 변형중 하나를 상속받아야 합니다.
8.3.1. 잘 조정된 리포지토리 선언
리포지토리 인터페이스를 시작할 수 있는 몇가지 변형이 있다.
전형적인 접근은 CRUD 기능의 메소드들을 제공하는 CrudRepository를 상속받는 것이다. CRUD는 생성, 읽기, 수정, 삭제를 나타낸다. 버전 3.0과 함께 우리는 또한 CrudRepository와 매우 유사한 ListCrudRepository를 도입했지만, 여러 엔터티를 리턴하는 메소드의 경우 사용하기 편할 수 있는 Iterable 대신에 List를 리턴한다.
만약 반응형 스토어를 사용한다면, 사용하는 반응형 프레임워크에 따라 ReactiveCrudRepository나 RxJava3CrudRepository를 선택할 수 있다.
코틀린을 사용한다면, 코틀린 coroutines를 이용하는 CorutineCrudRepository를 선택할 수 있다.
추가로 Pageable 추상이나 Sort 추상하는 메소드들이 필요하다면, PagingAndSortingRepository, ReactiveSortingRepository, RxJava3SortingRepository, CoroutineSortingRepository 등을 상속받을 수 있다. 스프링 데이타 버전 3.0 이전에 그랬던 것 처럼 여러개의 정력 리포지토리들이 더 이상 그들의 반응형 CRUD 리포지토리를 상속받지 않는다. 그러므로, 둘 다의 기능을 원하면 양 쪽 인터페이스를 모두 상속받아야 한다.
스프링 데이타 인터페이스를 상속받지 않기를 원한다면, @RepositoryDefinition 으로 리포지토리 인터페이스에 어노테이션 붙일 수 있다. 당신의 엔터티들을 조작할 메소드의 완성된 뭉치로 노출된 CRUD 리포지토리 인터페이스 중 하나가 상속된다. 노출된 메소드들중 선택적으로 사용하기를 원하면, 당신의 도메인 리포지토리로 CRUD 리포지토리에서 노출시켜서 원하는 메소드들을 카피해라. 그러면, 메소드의 리턴타입을 바꿀 수도 있다. 스프링 데이터는 가능한한 리턴타입을 리턴할 것이다. 예를 들면, Iterable<T>, List<T>, Colleciton<T> 나 VAVR 리스트 중 선택해서 여러개의 엔터티들을 리턴하는 메소드등이 있다.
만약 같은 메소드 뭉치를 가진 리포지토리들이 당신 애플리케이션에 있으면, 상속시켜줄 당신만의 베이스 인터페이스를 정의할 수 있다. 그런 인터페이스는 @NoRepositoryBean 애노테이션이 붙어야만 한다. 이 애노테이션은 스프링 데이터가 이것의 인스턴스를 직접만들려다 실패하는 것을 막아준다. 왜냐하면, 이것이 일반적인 타입 변수를 가지지않는한, 리포지토리의 엔터티를 정의할 수 없기 때문이다.
다음 예는 어떻게 선택적으로 CRUD 메소드를 노출하는지 보여준다(findById 와 save, 이예에서는)
Example 7. Selectively exposing CRUD methods
@NoRepositoryBean
interface MyBaseRepository<T, ID> extends Repository<T, ID> {
Optional<T> findById(ID id);
<S extends T> S save(S entity);
}
interface UserRepository extends MyBaseRepository<User, Long> {
User findByEmailAddress(EmailAddress emailAddress);
}예제에서, 모든 도메인 리포지토리에서 사용할 공통 베이스 인터페이스를 정의하고 save와 findById로 노출시켰다. 이 메소드들은 스프링 데이타에 의해 선태적으로 제공되는 스토어의 베이스 리포지토리 구현체로 연결된다.(예를들어, JPA를 사용하면, 이 구현체는 SimpleJpaRepository이다), 왜냐하면, CrudRepository에 있는 메소드 시그니쳐에 매칭되기 때문이다. 그래서, UserRepository는 이제 users를 저장할 수 있고, ID로 users를 찾을 수 있고, 이메일 주소로 User를 찾는 쿼리를 실행시킬 수 있다.
(알림)
이 중간 매게 리포지토리 인터페이스는 @NoRepositoryBean 애노테이션이 붙어야 한다. 런타임에 스프링 데이터가 인스턴스를 생성하지 말아야 할 모든 리포지토리 인터페이스에 애노테이션을 추가해서 안 헷갈리게 해라.
댓글