定义仓库接口
要定义仓库接口，首先需要定义一个特定于域类的仓库接口。该接口必须继承 Repository 并指定域类和 ID 类型。如果您想暴露该域类型的 CRUD 方法，您可以继承 CrudRepository 或其变体之一，而不是 Repository。
微调仓库定义
您可以通过几种不同的方式开始使用您的仓库接口。
典型的方法是继承 CrudRepository，它提供了 CRUD 功能的方法。CRUD 代表创建（Create）、读取（Read）、更新（Update）、删除（Delete）。从 3.0 版本开始，我们还引入了 ListCrudRepository，它与 CrudRepository 非常相似，但对于那些返回多个实体的方法，它返回 List 而不是 Iterable，这可能更易于使用。
如果您使用的是响应式存储，您可以选择 ReactiveCrudRepository 或 RxJava3CrudRepository，具体取决于您使用的响应式框架。
如果您正在使用 Kotlin，可以选择 CoroutineCrudRepository，它利用了 Kotlin 的协程。
此外，如果您需要允许指定 Sort 抽象或在第一种情况下指定 Pageable 抽象的方法，您可以继承 PagingAndSortingRepository、ReactiveSortingRepository、RxJava3SortingRepository 或 CoroutineSortingRepository。请注意，各种排序仓库不再像 Spring Data 3.0 版本之前那样继承其各自的 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 { … }
