定义资源库接口
要定义一个资源库接口，首先需要定义一个特定于领域类的资源库接口。该接口必须扩展`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`）
@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模块绑定到资源库定义。
-
如果资源库定义扩展了特定于模块的资源库，则它是特定Spring Data模块的有效候选者。
-
如果领域类使用特定于模块的类型注解进行注解，则它是特定Spring Data模块的有效候选者。Spring Data模块接受第三方注解（例如JPA的`@Entity`）或提供自己的注解（例如Spring Data MongoDB和Spring Data Elasticsearch的`@Document`）。
以下示例显示一个使用特定于模块的接口（在本例中为JPA）的资源库
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模块的有效候选者。
以下示例显示一个使用泛型接口的资源库
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。
以下示例显示一个使用带注解的领域类的资源库
interface PersonRepository extends Repository<Person, Long> { … }
@Entity
class Person { … }
interface UserRepository extends Repository<User, Long> { … }
@Document
class User { … }`PersonRepository`引用`Person`，它使用JPA `@Entity`注解进行注解，因此该资源库显然属于Spring Data JPA。`UserRepository`引用`User`，它使用Spring Data MongoDB的`@Document`注解进行注解。
以下错误示例显示一个使用混合注解的领域类的资源库
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 { … }
