SpringData JPA에서 CrudRepository와 JpaRepository 인터페이스의 차이점은 무엇입니까?

SpringData JPA에서 CrudRepository와 JpaRepository 인터페이스의 차이점은 무엇입니까?

---

SpringData JPA의 CrudRepository및 JpaRepository인터페이스 의 차이점은 무엇입니까 ?

웹에서 예제를 보면 그것들이 서로 바꿔서 사용되는 것을 볼 수 있습니다. 그들 사이의 차이점은 무엇입니까? 왜 다른 하나를 사용하고 싶습니까?

---

JpaRepository확장 PagingAndSortingRepository차례로 확장 한 CrudRepository.

주요 기능은 다음과 같습니다.

• CrudRepository 주로 CRUD 기능을 제공합니다.
• PagingAndSortingRepository 페이지 매김 및 레코드 정렬 방법을 제공합니다.
• JpaRepository 지속성 컨텍스트 플러시 및 배치에서 레코드 삭제와 같은 일부 JPA 관련 방법을 제공합니다.

위에서 언급 한 상속으로 인해는 및의 JpaRepository모든 기능을 갖습니다 . 따라서 및 에서 제공하는 함수를 사용할 저장소가 필요하지 않은 경우 .CrudRepositoryPagingAndSortingRepositoryJpaRepositoryPagingAndSortingRepositoryCrudRepository

---

Ken의 대답은 기본적으로 옳지 만 "왜 하나를 다른 것보다 사용하고 싶습니까?"에 차임하고 싶습니다. 질문의 일부입니다.

기초

저장소에 대해 선택한 기본 인터페이스에는 두 가지 주요 용도가 있습니다. 먼저, SpringData 저장소 인프라가 인터페이스를 찾고 프록시 생성을 트리거하여 인터페이스의 인스턴스를 클라이언트에 주입하도록 허용합니다. 두 번째 목적은 추가 메서드를 선언 할 필요없이 필요한만큼의 기능을 인터페이스로 가져 오는 것입니다.

공통 인터페이스

SpringData 코어 라이브러리는 전용 기능 세트를 노출하는 두 개의 기본 인터페이스와 함께 제공됩니다.

• CrudRepository -CRUD 방법
• PagingAndSortingRepository-페이지 매김 및 정렬 방법 (확장 CrudRepository)

매장 별 인터페이스

개별 스토어 모듈 (예 : JPA 또는 MongoDB 용)은 이러한 기본 인터페이스의 스토어 별 확장을 노출하여 일부 스토어 특성을 고려하는 플러싱 또는 전용 배치와 같은 스토어 별 기능에 액세스 할 수 있도록합니다. 이에 대한 예는 다음 deleteInBatch(…)의 JpaRepository다른 어떤 delete(…)더 확대됨이지만 (사양 정의 그것과 같은) JPA 정의 캐스케이드를 유발하지 않는 부작용 붙어 지정된 엔티티를 삭제 쿼리를 사용한다.

일반적으로 이러한 기본 인터페이스는 클라이언트에 기본 지속성 기술을 노출하여 이들과 리포지토리 간의 결합을 강화하므로 사용 하지 않는 것이 좋습니다 . 또한 기본적으로 "엔티티 모음"인 저장소의 원래 정의에서 약간 벗어납니다. 따라서 가능하다면 PagingAndSortingRepository.

사용자 정의 저장소 기본 인터페이스

제공된 기본 인터페이스 중 하나에 직접 의존하는 단점은 두 가지입니다. 둘 다 이론적 인 것으로 간주 될 수 있지만 다음 사항에 유의하는 것이 중요하다고 생각합니다.

1. SpringData 저장소 인터페이스에 따라 저장소 인터페이스를 라이브러리에 연결합니다. 나는 당신이 아마 같은 추상화를 사용하는 것 같은이 특정 문제라고 생각하지 않습니다 Page또는 Pageable어쨌든 코드에서. SpringData는 commons-lang 또는 Guava와 같은 다른 범용 라이브러리와 다르지 않습니다. 합리적인 혜택을 제공하는 한 괜찮습니다.
2. 예를 들어 확장 CrudRepository하면 한 번에 완전한 지속성 메소드 세트를 노출 할 수 있습니다. 이것은 대부분의 상황에서도 괜찮지 만 노출 된 메서드에 대해보다 세밀한 제어를 얻고 싶은 상황에 처할 수 있습니다. 예를 들어 ReadOnlyRepository의 save(…)및 delete(…)메서드를 포함하지 않는를 만드는 경우 입니다 CrudRepository.

이 두 가지 단점에 대한 해결책은 고유 한 기본 저장소 인터페이스 또는 그 세트를 만드는 것입니다. 많은 응용 프로그램에서 다음과 같은 것을 보았습니다.

interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }

interface ReadOnlyRepository<T> extends Repository<T, Long> {

  // Al finder methods go here
}

첫 번째 저장소 인터페이스는 실제로 포인트 1 만 수정하지만 Long일관성을 위해 ID 유형을 연결하는 범용 기본 인터페이스입니다 . 두 번째 인터페이스는 일반적으로 모든이 find…(…)복사 방법 CrudRepository등을 PagingAndSortingRepository하지만, 조작하는 사람을 노출하지 않습니다. 참조 문서 에서 해당 접근 방식에 대해 자세히 알아보십시오 .

요약-tl; dr

The repository abstraction allows you to pick the base repository totally driven by you architectural and functional needs. Use the ones provided out of the box if they suit, craft your own repository base interfaces if necessary. Stay away from the store specific repository interfaces unless unavoidable.

---

Summary:

• PagingAndSortingRepository extends CrudRepository

• JpaRepository extends PagingAndSortingRepository

The CrudRepository interface provides methods for CRUD operations, so it allows you to create, read, update and delete records without having to define your own methods.

The PagingAndSortingRepository provides additional methods to retrieve entities using pagination and sorting.

Finally the JpaRepository add some more functionality that is specific to JPA.

---

I am learning Spring Data JPA. It might help you:

참고URL : https://stackoverflow.com/questions/14014086/what-is-difference-between-crudrepository-and-jparepository-interfaces-in-spring