有几种变体可以让你开始使用你的 repository 接口。

典型的方法是继承 CrudRepository，它为你提供了 CRUD 功能的方法。CRUD是指创建、读取、更新、删除。在3.0版本中，我们还引入了 ListCrudRepository，它与 CrudRepository 非常相似，但对于那些返回多个实体的方法，它返回一个 List 而不是一个 Iterable，你可能会发现它更容易使用。

如果你使用的是响应式store，你可以选择 ReactiveCrudRepository，或者 RxJava3CrudRepository，这取决于你使用的是哪种响应式框架。

如果你使用的是Kotlin，你可以选择 CoroutineCrudRepository，它利用了Kotlin的 coroutine（协程）。

额外的你可以扩展 PagingAndSortingRepository、ReactiveSortingRepository、RxJava3SortingRepository 或 CoroutineSortingRepository，如果你需要允许指定一个 Sort 抽象的方法，或者在第一种情况下是 Pageable 抽象。请注意，各种排序 repository 不再像Spring Data 3.0之前的版本那样扩展各自的CRUD库。因此，如果你想获得这两个接口的功能，你需要扩展这两个接口。

如果你不想扩展Spring Data接口，你也可以用 @RepositoryDefinition 来注解你的 repository 接口。扩展CRUD repository 接口之一会暴露出一套完整的方法来操作你的实体。如果你想对暴露的方法有所选择，可以从CRUD repository 复制你想暴露的方法到你的 domain repository。这样做时，你可以改变方法的返回类型。如果可能的话，Spring Data会尊重返回类型。例如，对于返回多个实体的方法，你可以选择 Iterable<T>、List<T>、Collection<T> 或 VAVR list

如果你的应用程序中的许多 repository 应该有相同的方法集，你可以定义你自己的基础接口来继承。这样的接口必须用 @NoRepositoryBean 来注释。这可以防止Spring Data试图直接创建它的实例而导致异常，因为它仍然包含一个泛型变量，Spring data 无法确定该 repository 的实体。

下面的例子展示了如何有选择地公开CRUD方法（本例中为 findById 和 save）。

在前面的例子中，你为所有的 domain repository 定义了一个通用的基础接口，并暴露了 findById(…​) 以及 save(…​)。这些方法被路由到Spring Data提供的你所选择的store的基础 repository 实现（例如，如果你使用JPA，实现是 SimpleJpaRepository），因为它们与 CrudRepository 中的方法签名一致。 所以 UserRepository 现在可以保存用户，通过ID查找单个用户，通过电子邮件地址查找 User。

在你的应用程序中使用一个独特的Spring Data模块使事情变得简单，因为定义范围内的所有 repository 接口都绑定到Spring Data模块。有时，应用程序需要使用一个以上的Spring Data模块。在这种情况下，repository 定义必须区分持久化技术。当它检测到类路径上有多个 repository 工厂时，Spring Data会进入严格的 repository 配置模式。严格的配置使用 repository 或domain类的细节来决定 repository 定义的Spring Data模块绑定。

下面的例子显示了一个使用特定模块接口的 repository（本例中为JPA）。

下面的例子显示了一个使用通用（泛型）接口的 repository。

下面的例子显示了一个使用带注解的domain类的repository。

下面的坏例子显示了一个使用混合注解的 domain 类的 Repository。

Repository 类型细节和区分domain类注解用于严格的repository库配置，以确定特定Spring Data模块的repository候选者。在同一domain类型上使用多个持久化技术的特定注解是可能的，并且能够在多个持久化技术中重复使用domain类型。然而，Spring Data就不能再确定一个唯一的模块来绑定repository了。

区分 repository 的最后一个方法是通过对 repository base package的扫描。base package 定义了扫描 repository 接口定义的起点，这意味着将 repository 的定义放在适当的包中。默认情况下，注解驱动的配置使用配置类所在的base package。基于XML的配置中的base package，需要手动强制配置。

下面的例子显示了注解驱动的 base package 的配置。

下列策略可用于 repository 基础设施解析查询。 对于 Java 配置，你可以使用 EnableJpaRepositories 注解的 queryLookupStrategy 属性。有些策略可能不支持特定的datastore。

内置在Spring Data repository 基础架构中的查询 builder 机制对于在资源库的实体上建立约束性查询非常有用。

下面的例子展示了如何创建一些查询。

解析查询方法名称分为主语和谓语。第一部分（find…​By, exists…​By）定义了查询的主语，第二部分形成谓语。引入句（主语）可以包含进一步的表达。在 find（或其他引入关键词）和 By 之间的任何文本都被认为是描述性的，除非使用一个限制结果的关键词，如 Distinct 在要创建的查询上设置一个不同的标志，或 Top / First 来限制查询结果。

附录中包含了 查询方法主语关键词 和 查询方法谓语关键词的完整列表，包括排序和字母修饰语。然而，第一个 By 作为分界符，表示实际条件谓词的开始。在一个非常基本的层面上，你可以在实体属性上定义条件，并用 And 和 Or 来连接它们。

解析方法的实际结果取决于你为之创建查询的持久性store。然而，有一些东西需要注意。

属性表达式只能引用被管理实体的一个直接属性，如前面的例子所示。在查询创建时，你已经确保解析的属性是被管理的domian类的一个属性。然而，你也可以通过遍历嵌套属性来定义约束。考虑一下下面的方法签名。

假设 Person 有一个带有 ZipCode 的 Address。在这种情况下，该方法创建 x.address.zipCode 属性遍历。解析算法首先将整个部分（AddressZipCode）解释为属性，并检查domain类中是否有该名称的属性（未加首字母）。如果算法成功，它就使用该属性。如果没有，该算法将源头的驼峰字母部分从右侧分割成一个头和一个尾，并试图找到相应的属性—​在我们的例子中，是 AddressZip 和 Code。如果该算法找到了具有该头部的属性，它就取其尾部，并从那里继续向下构建树，以刚才描述的方式将尾部分割开来。如果第一次分割不匹配，该算法将分割点移到左边（Address, ZipCode）并继续。

虽然这在大多数情况下应该是有效的，但该算法有可能选择错误的属性。假设 Person 类也有一个 addressZip 属性。该算法将在第一轮分割中已经匹配，选择错误的属性，并且失败（因为 addressZip 的类型可能没有 code 属性）。

为了解决这个模糊的问题，你可以在你的方法名里面使用 _ 来手动定义遍历点。因此，我们的方法名称将如下。

因为我们把下划线字符当作一个保留字符，所以我们强烈建议遵循标准的Java命名惯例（也就是说，不要在属性名中使用下划线，而要使用驼峰大写）。

为了处理你的查询中的参数，定义方法参数，正如在前面的例子中已经看到的。除此之外，基础设施还能识别某些特定的类型，如 Pageable 和 Sort，以动态地将分页和排序应用于你的查询。下面的例子演示了这些功能。

第一个方法让你把 org.springframework.data.domain.Pageable 实例传递给 query 方法，以动态地将分页添加到你静态定义的查询中。一个 Page 知道可用的元素和页面的总数。它是通过基础设施触发一个 count 查询来计算总数量。由于这可能是昂贵的（取决于使用的store），你可以返回一个 Slice。一个 Slice 只知道下一个 Slice 是否可用，当遍历一个较大的结果集时，这可能就足够了。

排序选项也是通过 Pageable 实例处理的。如果你只需要排序，在你的方法中加入 org.springframework.data.domain.Sort 参数。正如你所看到的，返回一个 List 也是可能的。在这种情况下，构建实际的 Page 实例所需的额外元数据并没有被创建（这反过来意味着不需要发出额外的 count 查询）。相反，它限制了查询，只查询给定范围的实体。

你可以通过使用 first 或 top 关键字来限制查询方法的结果，这两个关键字可以互换使用。你可以在 top 或 first 后面附加一个可选的数值，以指定要返回的最大结果大小。如果不加数字，就会假定结果大小为 1。下面的例子显示了如何限制查询的大小。

对于支持不同查询的数据集，限制表达式也支持 Distinct 关键字。另外，对于将结果集限制在一个实例的查询，支持用 Optional 关键字将结果包入。

如果分页或 slice 应用于 limit 查询的分页（以及可用页数的计算），则会在 limit 结果中应用。

返回多个结果的查询方法可以使用标准的Java Iterable、List 和 Set。除此之外，我们还支持返回Spring Data的 Streamable，这是 Iterable 的一个自定义扩展，以及 Vavr 提供的 collection 类型。请参考附录中对所有可能的 查询方法返回类型的解释。

从Spring Data 2.0开始，返回单个聚合实例的 repository CRUD方法使用Java 8的 Optional 来表示可能没有的值。除此之外，Spring Data还支持在查询方法上返回以下 wrapper 类型。

另外，查询方法可以选择完全不使用 wrapper 类型。没有查询结果的话会通过返回 null 来表示。Repository 方法返回集合、集合替代物、wrapper和流时，保证不会返回 null，而是返回相应的空（Empty）表示。详见 “Repository 查询返回类型”。

你可以通过使用Java 8 Stream<T> 作为返回类型来增量地处理查询方法的结果。如下面的例子所示，不把查询结果包裹在 Stream 中，而是使用 data store 的特定方法来执行流式处理。

你可以通过使用 Spring的异步方法运行能力 来异步运行 repository 查询。这意味着该方法在调用后立即返回，而实际的查询发生在一个已经提交给Spring TaskExecutor 的任务中。异步查询与响应式查询不同，不应混合使用。关于响应式支持的更多细节，请参见store的特定文档。下面的例子显示了一些异步查询的案例。

在Java配置类上使用store特有的 @EnableJpaRepositories 注解来定义 repository 激活的配置。关于基于Java的Spring容器配置的介绍，请参见 Spring参考文档中的JavaConfig。

启用 Spring Data Repository 的示例配置类似于以下内容。

默认情况下，基础架构会抓取每个扩展了位于配置的 base package 下的持久化技术特定的 Repository 子接口的接口，并为其创建一个Bean实例。然而，你可能想要更精细地控制哪些接口为其创建Bean实例。要做到这一点，可以在 Repository 声明中使用 filter 元素。其语义与Spring的组件过滤器中的元素完全等同。详情请见 Spring参考文档 中的这些元素。

例如，为了排除某些接口作为 Repository Bean 的实例化，你可以使用以下配置。

前面的例子排除了所有以 SomeRepository 结尾的接口被实例化，包括以 SomeOtherRepository 结尾的接口。

你也可以在Spring容器之外使用资源库基础设施—​例如，在CDI环境中。你仍然需要在你的classpath中使用一些Spring库，但是，一般来说，你也可以通过编程来设置 Repository。Repository 支持的Spring Data模块都有一个特定于持久化技术的 RepositoryFactory，你可以使用，如下所示。

要用自定义的功能来丰富 repository，你必须首先定义一个片段（fragment）接口和自定义功能的实现，如下所示。

实现本身并不依赖于Spring Data，它可以是一个普通的Spring Bean。因此，你可以使用标准的依赖注入行为来注入对其他Bean（如 JdbcTemplate）的引用，参与到各个切面，等等。

然后你可以让你的 repository 接口继承片段接口，如下所示。

用你的存储库接口继承片段接口，结合了CRUD和自定义功能，并使其对客户端可用。

Spring Data Repository 是通过使用形成 repository 组合的片段来实现的。片段是基础repository、功能方面（如 QueryDsl），以及自定义接口和它们的实现。每当你为你的repository接口添加一个接口，你就通过添加一个片段来增强组合。基础repository和repository方面的实现是由每个Spring Data模块提供的。

下面的例子显示了自定义接口和它们的实现。

下面的例子显示了一个扩展了 CrudRepository 的自定义 repository 的接口。

Repository可以由多个自定义实现组成，这些自定义实现按其声明的顺序被导入。自定义实现的优先级高于基础实现和Repository 切面。这种排序可以让你覆盖基础Repository和切面的方法，并在两个片段贡献了相同的方法签名时解决歧义。Repository片段不限于在单一存储库接口中使用。多个Repository可以使用一个片段接口，让你在不同的 Repository 中重复使用自定义的内容。

下面的例子显示了一个 Repository 片段及其实现。

下面的例子显示了一个使用前述 repository 片段的 repository。

当你想定制基础 repository 的行为时，上一节描述的方法需要定制每个 repository 的接口，以便所有的 repository 都受到影响。为了改变所有 repository 的行为，你可以创建一个扩展持久化技术特定 repository 基类的实现。然后这个类作为 repository 代理的自定义基类，如下面的例子所示。

最后一步是让Spring Data基础设施意识到定制的 repository base 类。在配置中，你可以通过使用 repositoryBaseClass 来做到这一点，如下面的例子所示。

Querydsl 是一个框架，可以通过其 fluent API构建静态类型的类似SQL的查询。

一些Spring Data模块通过 QuerydslPredicateExecutor 提供与 Querydsl 的集成，正如下面的例子所示。

为了使用 Querydsl 支持，在你的版本库接口上扩展 QuerydslPredicateExecutor，如下面的例子所示。

前面的例子让你通过使用 Querydsl Predicate 实例来编写类型安全的查询，如下图所示。

支持 repository 编程模型的Spring Data模块带有各种Web支持。web相关的组件需要添加 Spring MVC 到项目。其中一些甚至提供了与 Spring HATEOAS的整合。一般来说，集成支持是通过在你的 JavaConfig 配置类中使用 @EnableSpringDataWebSupport 注解来启用的，如下面例子所示。

@EnableSpringDataWebSupport 注解注册了一些组件。我们将在本节后面讨论这些组件。它还会检测classpath上的Spring HATEOAS，并为其注册整合组件（如果存在）。

Spring Data JDBC 使用 Dialect 接口的实现来封装特定于数据库或其JDBC驱动程序的行为。默认情况下，AbstractJdbcConfiguration 会尝试确定正在使用的数据库并注册正确的 Dialect。这个行为可以通过覆写 jdbcDialect(NamedParameterJdbcOperations) 来改变。

如果你使用一个没有方言（Dialect）的数据库，那么你的应用程序将无法启动。在这种情况下，你将不得不要求你的供应商提供一个方言实现。另外，你也可以：

本节涵盖了Spring Data对象映射、对象创建、字段和属性访问、可变性和不可变性的基本原理。注意，本节只适用于不使用底层数据存储的对象映射的Spring Data模块（如JPA）。此外，请务必查阅特定于存储的对象映射部分，如索引、自定义列或字段名或类似内容。

Spring Data对象映射的核心职责是创建domain对象的实例，并将存储的本地数据结构映射到这些对象上。这意味着我们需要两个基本步骤。

目前支持以下类型的属性。

当你使用 Spring Data JDBC 提供的 CrudRepository 的标准实现时，它们期望有一个特定的表结构。你可以通过在你的 application context 中提供 NamingStrategy 来进行调整。

当 NamingStrategy 不匹配你的数据库表名时，你可以用 @Table 注解来定制名称。该注解的 value 值提供了自定义表的名称。下面的例子将 MyEntity 类映射到数据库中的 CUSTOM_TABLE_NAME 表。

当 NamingStrategy 不匹配你的数据库列名时，你可以用 @Column 注解来定制名称。这个注解的 value 值提供了自定义的列名。下面的例子将 MyEntity 类的 name 属性映射到数据库中的 CUSTOM_COLUMN_NAME 列。

@MappedCollection 注解可用于引用类型（一对一的关系）或Set、List和Map（一对多的关系）。注解的 idColumn 元素为引用对方表中 id 列的外键列提供了一个自定义名称。在下面的例子中，MySubEntity 类的对应表有一个 NAME 列，而 MyEntity id 的 CUSTOM_MY_ENTITY_ID_COLUMN_NAME 列是出于关系的原因。

当使用 List 和 Map 时，你必须为 List 中数据集的 position 或 Map 中实体的 key 值设置一个额外的列。这个额外的列名可以通过 @MappedCollection 注解的 keyColumn 元素来定制。

嵌入式实体用于在你的java数据模型中的 value 对象，即使你的数据库中只有一个表。在下面的例子中，你可以看到 MyEntity 是用 @Embedded 注解来映射的。这样做的结果是，在数据库中，预期会有一个带有两列 id 和 name（来自 EmbeddedEntity 类）的表 my_entity。

然而，如果 name 列在结果集中实际上是 null，根据 @Embedded 的 onEmpty，整个属性 embeddedEntity 将被设置为 null，当所有嵌套的属性都是 null 的时候，它就会将对象设置为 null。 与这种行为相反，USE_EMPTY 试图使用默认的构造函数或接受结果集的可空参数值的构造函数来创建一个新的实例。

如果你在一个实体中多次需要一个 value 对象，这可以通过 @Embedded 注解的可选的 prefix 元素来实现。这个元素代表一个前缀，并为嵌入对象中的每一列名称预置。

包含一个 Collection 或 Map 的嵌入式实体将总是被认为是非空的，因为它们至少会包含空的Collection或Map。因此，即使使用 @Embedded(onEmpty = USE_NULL)，这样的实体也不会为 null。

下表描述了Spring Data为检测一个实体是否是新的提供的策略。

Spring Data JDBC 使用ID来识别实体。实体的 ID 必须用 Spring Data 的 @Id 注解来注解。

当你的数据库中的ID列有一个自增列时，在将实体插入数据库后，生成的值会被设置到实体中。

一个重要的约束条件是，在保存一个实体之后，该实体必须不再是新的了。请注意，一个实体是否是新的是实体状态的一部分。对于自动递增列，这种情况会自动发生，因为Spring Data会用ID列的值来设置ID。如果你不使用自动递增列，你可以使用 BeforeConvert 监听器，它可以设置实体的ID（在本文后面会提到）。

用 @ReadOnlyProperty 注解的属性不会被Spring Data JDBC写入数据库，但它们会在实体被加载时被读取。

Spring Data JDBC在写入实体后不会自动重新加载它。因此，如果你想看到在数据库中为这些列生成的数据，你必须明确地重新加载它。

如果被注解的属性是一个实体或实体的集合，那么它将由单独表中的一个或多个单独的行来表示。Spring Data JDBC将不会对这些行进行任何插入、删除或更新。

用 @InsertOnlyProperty 注解的属性将只在插入操作期间由 Spring Data JDBC 写入数据库。对于更新，这些属性将被忽略。

@InsertOnlyProperty 仅支持 aggregate root。

Spring Data JDBC 通过在 aggregate root 上用 @Version 注解的数字属性来支持乐观锁。每当Spring Data JDBC保存一个带有这种 version 属性的aggregate 时，就会发生两件事。aggregate root 的更新语句将包含一个where子句，检查存储在数据库中的版本是否真的没有变化。如果不是这样，就会抛出 OptimisticLockingFailureException。同时， version 属性在实体和数据库中都会被增加，所以一个并发的动作会注意到这个变化，并抛出一个 OptimisticLockingFailureException（如果适用），如上所述。

这个过程也适用于插入新的聚合体，null 或 0 version 表示一个新的实例，之后增加的实例标志着该实例不再是新的，这使得在对象构建过程中产生的 id 相当好，例如使用UUID时。

在删除过程中，版本检查也适用，但不会增加版本。

JDBC模块支持将查询手动定义为 @Query 注解中的一个字符串或在 property 文件中的命名查询。

从方法的名称衍生出的查询目前仅限于简单的属性，也就是直接存在于 aggregate root 中的属性。另外，这种方法只支持 select 查询。

下面的例子显示了如何使用 @Query 来声明一个查询方法。

对于将查询结果转换为实体，默认使用与Spring Data JDBC自己生成的查询相同的 RowMapper。你提供的查询必须符合 RowMapper 所期望的格式。必须提供在实体的构造函数中使用的所有属性的列。通过 setter、with 或字段访问而被设置的属性的列是可选的。在结果中没有匹配列的属性将不会被设置。该查询用于填充aggregate root、嵌入式实体和一对一的关系，包括原始类型的数组，这些数组被存储和加载为SQL-array-types。对于实体的map、list、collection和数组会产生单独的查询。

如果在上一节所述的注解中没有给出查询，Spring Data JDBC将尝试定位一个命名的查询。有两种方法可以确定查询的名称。默认的方法是取查询的domain类，即资源库的aggregate root，取其简称，并附加以 . 分隔的方法的名称。另外，@Query 注解有一个 name 属性，可以用来指定要查找的查询的名称。

命名查询应该在classpath上的 META-INF/jdbc-named-queries.properties property 文件中提供。

该文件的位置可以通过给 @EnableJdbcRepositories.namedQueriesLocation 设置一个值来改变.

本章介绍了 "Example 查询" 并解释了如何使用它。

Example 查询（QBE）是一种用户友好的查询技术，接口简单。它允许动态查询创建，不要求你写包含字段名的查询。事实上，"Example 查询" 根本不要求你通过使用store特定的查询语言来编写查询。

Example 查询API由四部分组成。

Example 查询很适合几种使用情况。

Example 查询也有一些限制。

在开始使用Example 查询之前，你需要有一个domain对象。为了开始，为你的 repository 创建一个接口，如下面的例子所示。

前面的例子显示了一个简单的domain对象。你可以用它来创建一个 Example。默认情况下，具有 null 值的字段会被忽略，而字符串则通过使用store特定的默认值进行匹配。

例子可以通过使用工厂方法或通过使用 ExampleMatcher 来构建。Example 是不可改变的。下面的列表显示了一个简单的例子。

你可以通过使用 repository 来运行示例查询。要做到这一点，让你的 repository 接口扩展 QueryByExampleExecutor<T>。下面的列表显示了 QueryByExampleExecutor 接口的一个节选。

示例不限于默认设置。你可以通过使用 ExampleMatcher 为字符串匹配、null处理和特定属性设置指定你自己的默认值，如下面的例子所示。

默认情况下，ExampleMatcher 希望 probe 上设置的所有值都能匹配。如果你想得到与任何隐式定义的谓词（predicate）相匹配的结果，请使用 ExampleMatcher.matchingAny()。

你可以为单个属性（如 "firstname" 和 "lastname"，或者对于嵌套属性，"address.city"）指定行为。你可以用匹配选项和大小写敏感性来调整它，如下面的例子所示。

配置 matcher 选项的另一种方法是使用 lambda （在Java 8中引入）。这种方法创建一个回调，要求实现者修改matcher。你不需要返回matcher，因为配置选项被保存在matcher实例中。下面的例子显示了一个使用lambda的matcher。

Example 创建的查询使用的是配置的合并视图。默认的匹配设置可以在 ExampleMatcher 层面上设置，而个别设置可以应用于特定的属性路径。在 ExampleMatcher 上设置的设置会被属性路径设置所继承，除非它们被明确定义。属性补丁（patch）上的设置比默认设置有更高的优先权。下表描述了各种 ExampleMatcher 设置的范围。

QueryByExampleExecutor 还提供了一个方法，我们到目前为止还没有提到。<S extends T, R> R findBy(Example<S> example, Function<FluentQuery.FetchableFluentQuery<S>, R> queryFunction) 。和其他方法一样，它执行一个从 Example 派生的查询。然而，通过第二个参数，你可以控制该执行的各个方面，否则你无法动态地控制。你可以通过调用第二个参数中的 FetchableFluentQuery 的各种方法来做到这一点。 sortBy 让你为你的结果指定一个排序。as 让你指定你希望结果被转换的类型。project 限制了被查询的属性。first, firstValue, one, oneValue, all, page, stream, count, 和 exists 定义了你得到什么样的结果以及当超过预期结果数量时查询的行为方式。

在Spring Data JDBC中，你可以使用 Repository 的 Query by Example，如以下例子所示。

property specifier （属性指定器）接受属性名称（如 firstname 和 lastname）。你可以通过将属性用点连接起来进行导航（address.city）。你还可以用匹配选项和大小写敏感性来调整它。

下表显示了你可以使用的各种 StringMatcher 选项以及在一个名为 firstname 的字段上使用这些选项的结果。

Spring Data的查询方法通常会返回由 repository 管理的聚合根(aggregate root)的一个或多个实例。 然而，有时可能需要根据这些类型的某些属性来创建投影。 Spring Data允许建模专用的返回类型，以更有选择地检索管理的聚合体（aggregate）的部分视图。

想象一下，一个repository和聚合根类型，如下面的例子。

现在想象一下，我们只想检索这个人的 name 属性。Spring Data提供了什么手段来实现这一点？本章的其余部分将回答这个问题。

将MyBatis正确插入Spring Data JDBC的最简单方法是将 MyBatisJdbcConfiguration 导入到你的应用程序配置中。

正如你所看到的，你所需要声明的是一个 SqlSessionFactoryBean，因为 MyBatisJdbcConfiguration 依赖于一个 SqlSession Bean，最终在 ApplicationContext 中可用。

对于 CrudRepository 中的每个操作，Spring Data JDBC运行多个语句。如果 application context 中有一个 SqlSessionFactory，Spring Data 就会为每个步骤检查 SessionFactory 是否提供一个语句。如果找到了一个，就会使用该语句（包括其配置的对实体的映射）。

语句的名称是由实体类型的完全名称与 Mapper. 和决定语句类型的String连接而成的。例如，如果要插入 org.example.User 的实例，Spring Data JDBC会寻找一个名为 org.example.UserMapper.insert 的语句。

当语句运行时，[MyBatisContext] 的一个实例被作为参数传递，这使得各种参数对语句可用。

下表描述了可用的MyBatis语句。

Spring Data JDBC 使用 EntityCallback API来支持其审计，并对下表中列出的回调作出反应。

我们鼓励使用回调而不是事件，因为它们支持使用不可变的类，因此比事件更强大、更通用。

EntityCallback 通过其泛型类型参数与它的 domain 类型直接相关。每个Spring Data 模块通常都有一组预定义的 EntityCallback 接口，涵盖了实体的生命周期。

实现适合你的应用需求的接口，如下面的例子所示。

EntityCallback Bean 在 ApplicationContext 中注册的情况下被 store 的具体实现所接收。大多数模板API已经实现了 ApplicationContextAware，因此可以访问 ApplicationContext。

下面的例子解释了一个有效的实体回调注册的集合。

下面的例子显示了一个 Converter 的实现，它将一个 Boolean 对象转换为一个 String 值。

这里有几件事情需要注意。Boolean 和 String 都是简单的类型，因此Spring Data 需要提示这个converter应该在哪个方向上应用（读取或写入）。通过用 @WritingConverter 来注解这个converter，指示 Spring Data在数据库中将每个 Boolean 属性写成 String。

下面的例子显示了一个 Converter 的实现，它将 String 转换为 Boolean。

这里有几件事情需要注意。String 和 Boolean 都是简单的类型，因此Spring Data需要提示这个converter应该在哪个方向上应用（读或写）。通过用 @ReadingConverter 来注解这个converter，指示Spring Data从数据库中转换每个应该被分配给 Boolean 属性的 String 值。

值转换（Value conversion）使用 JdbcValue 来充实传播到JDBC操作中的具有 java.sql.Types 类型的值。如果你需要指定一个JDBC特定的类型，而不是使用类型派生，请注册一个自定义write converter。这个转换器应该将值转换为 JdbcValue，它有一个 value 和实际的 JDBCType 的字段。

下面是一个Spring Converter 实现的例子，它将一个 String 转换为一个自定义的 Email 值对象。

如果你编写的 Converter 的源类型和目标类型都是原生类型，我们无法确定我们应该把它看作是一个读或写的 Converter。将 Converter 实例注册为这两种类型可能会导致不必要的结果。例如，一个 Converter<String, Long> 是模棱两可的，尽管在写入时试图将所有的 String 实例转换成 Long 实例可能没有意义。为了让你强制基础设施只为一种方式注册转换器，我们提供了 @ReadingConverter 和 @WritingConverter 注解，以便在转换器实现中使用。

Converter 需要明确注册，因为实例不是从classpath或容器扫描中获取的，以避免在转换服务中进行不必要的注册以及这种注册产生的副作用。Converter 是通过 CustomConversions 注册的，它是一个中央设施，允许根据源和目标类型注册和查询已注册的 Converter。

CustomConversions 带有一套预先定义的转换器注册（converter registration）。

要让你的查询方法是事务性的，在你定义的 repository 接口处使用 @Transactional，如下例所示。

通常情况下，你希望 readOnly 标志被设置为 true，因为大多数的查询方法只读取数据。与此相反， deleteInactiveUsers() 使用了 @Modifying 注解并覆盖了事务配置。因此，该方法的 readOnly 标志被设置为 false。

Spring Data提供了复杂的支持，可以透明地跟踪谁创建或更改了实体以及更改发生的时间。为了从该功能中获益，你必须为你的实体类配备审计元数据，这些元数据可以使用注解或实现接口来定义。此外，审计必须通过注解配置或XML配置来启用，以注册所需的基础设施组件。关于配置样本，请参考特定store部分。