定义资源库接口

要定义一个资源库接口，首先需要定义一个特定于域类的资源库接口。该接口必须扩展Repository并针对域类和ID类型进行类型化。如果要公开该域类型的CRUD方法，则可以扩展CrudRepository或其变体，而不是Repository。

微调资源库定义

您可以通过几种不同的方式开始使用您的资源库接口。

典型的方法是扩展CrudRepository，这为您提供了CRUD功能的方法。CRUD代表创建、读取、更新、删除。在3.0版本中，我们还引入了ListCrudRepository，它与CrudRepository非常相似，但对于返回多个实体的方法，它返回List而不是Iterable，您可能会觉得更容易使用。

如果您使用的是反应式存储，您可以根据使用的反应式框架选择ReactiveCrudRepository或RxJava3CrudRepository。

如果您使用的是Kotlin，您可以选择CoroutineCrudRepository，它利用Kotlin的协程。

此外，如果您需要允许指定Sort抽象（或者在第一种情况下是Pageable抽象）的方法，您可以扩展PagingAndSortingRepository、ReactiveSortingRepository、RxJava3SortingRepository或CoroutineSortingRepository。请注意，与3.0之前的Spring Data版本不同，各种排序资源库不再扩展其各自的CRUD资源库。因此，如果您想要同时使用两种功能，则需要扩展这两个接口。

如果您不想扩展Spring Data接口，您也可以使用@RepositoryDefinition注解您的资源库接口。扩展一个CRUD资源库接口会公开一整套用于操作实体的方法。如果您希望选择要公开的方法，请将您希望公开的方法从CRUD资源库复制到您的域资源库中。这样做时，您可以更改方法的返回类型。Spring Data会尽可能地遵守返回类型。例如，对于返回多个实体的方法，您可以选择Iterable<T>、List<T>、Collection<T>或VAVR列表。

如果您的应用程序中的许多资源库应该具有相同的方法集，您可以定义自己的基接口来继承。此类接口必须用@NoRepositoryBean注解。这可以防止Spring Data直接尝试创建它的实例并失败，因为它无法确定该资源库的实体，因为它仍然包含一个泛型类型变量。

以下示例显示了如何选择性地公开CRUD方法（在本例中为findById和save）

选择性地公开CRUD方法
@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);
}

在前面的示例中，您为所有域资源库定义了一个通用的基接口，并公开了findById(…)和save(…)。这些方法被路由到Spring Data提供的您选择的存储的基资源库实现（例如，如果您使用JPA，则实现是SimpleJpaRepository），因为它们与CrudRepository中的方法签名匹配。因此，UserRepository现在可以保存用户、通过ID查找单个用户以及触发查询以通过电子邮件地址查找Users。

中间资源库接口使用@NoRepositoryBean注解。确保您将该注解添加到Spring Data不应在运行时创建实例的所有资源库接口。

使用多个Spring Data模块的资源库

在您的应用程序中使用唯一的Spring Data模块可以简化事情，因为定义范围内的所有资源库接口都绑定到Spring Data模块。有时，应用程序需要使用多个Spring Data模块。在这种情况下，资源库定义必须区分持久性技术。当它检测到类路径上的多个资源库工厂时，Spring Data会进入严格的资源库配置模式。严格的配置使用资源库或域类上的详细信息来决定Spring Data模块绑定对于资源库定义。

  1. 如果资源库定义扩展了特定于模块的资源库，则它是特定Spring Data模块的有效候选者。

  2. 如果域类使用特定于模块的类型注解进行注解，则它是特定Spring Data模块的有效候选者。Spring Data模块接受第三方注解（例如JPA的@Entity）或提供自己的注解（例如Spring Data MongoDB和Spring Data Elasticsearch的@Document）。

以下示例显示了一个使用特定于模块的接口（在本例中为JPA）的资源库

示例1. 使用特定于模块的接口的资源库定义
interface MyRepository extends JpaRepository<User, Long> { }

@NoRepositoryBean
interface MyBaseRepository<T, ID> extends JpaRepository<T, ID> { … }

interface UserRepository extends MyBaseRepository<User, Long> { … }

MyRepository和UserRepository在其类型层次结构中扩展JpaRepository。它们是Spring Data JPA模块的有效候选者。

以下示例显示了一个使用泛型接口的资源库

示例2. 使用泛型接口的资源库定义
interface AmbiguousRepository extends Repository<User, Long> { … }

@NoRepositoryBean
interface MyBaseRepository<T, ID> extends CrudRepository<T, ID> { … }

interface AmbiguousUserRepository extends MyBaseRepository<User, Long> { … }

AmbiguousRepository和AmbiguousUserRepository在其类型层次结构中只扩展Repository和CrudRepository。虽然在使用唯一的Spring Data模块时这很好，但多个模块无法区分这些资源库应绑定到哪个特定的Spring Data。

以下示例显示了一个使用带有注解的域类的资源库

示例3. 使用带有注解的域类的资源库定义
interface PersonRepository extends Repository<Person, Long> { … }

@Entity
class Person { … }

interface UserRepository extends Repository<User, Long> { … }

@Document
class User { … }

PersonRepository 引用了带有 JPA @Entity 注解的 Person，因此该仓库显然属于 Spring Data JPA。UserRepository 引用了带有 Spring Data MongoDB 的 @Document 注解的 User。

以下错误示例显示了一个使用混合注解的域类的仓库。

示例 4. 使用混合注解的域类的仓库定义
interface JpaPersonRepository extends Repository<Person, Long> { … }

interface MongoDBPersonRepository extends Repository<Person, Long> { … }

@Entity
@Document
class Person { … }

此示例显示了一个使用 JPA 和 Spring Data MongoDB 注解的域类。它定义了两个仓库，JpaPersonRepository 和 MongoDBPersonRepository。一个用于 JPA，另一个用于 MongoDB。Spring Data 无法再区分这些仓库，这会导致未定义的行为。

仓库类型详情 和 区分域类注解 用于严格的仓库配置，以识别特定 Spring Data 模块的仓库候选者。在同一个域类型上使用多个持久化技术特定的注解是可能的，并且可以跨多个持久化技术重用域类型。但是，Spring Data 无法再确定要与其绑定的唯一模块。

区分仓库的最后一种方法是通过范围限定仓库基础包。基础包定义了扫描仓库接口定义的起始点，这意味着仓库定义位于相应的包中。默认情况下，注解驱动的配置使用配置类的包。基于 XML 的配置中的基础包 是必需的。

以下示例显示了注解驱动的基础包配置。

注解驱动的基础包配置
@EnableJpaRepositories(basePackages = "com.acme.repositories.jpa")
@EnableMongoRepositories(basePackages = "com.acme.repositories.mongo")
class Configuration { … }