Spring Data Jpa框架最佳实践示例

前言

spring data jpa框架的目标是显著减少实现各种持久性存储的数据访问层所需的样板代码量。

spring data jpa存储库抽象中的*接口是repository。它需要领域实体类以及领域实体id类型作为类型参数来进行管理。该接口主要用作标记接口，以捕获要使用的类型并帮助您发现扩展该接口的接口。

crudrepository、jparepository是更具体的数据操作抽象，一般我们在项目中使用的时候定义我们的领域接口然后继承crudrepository或jparepository即可实现实现基础的curd方法了，但是这种用法有局限性，不能处理超复杂的查询，而且稍微复杂的查询代码写起来也不是很优雅，所以下面看看怎么最优雅的解决这个问题。

扩展接口用法

优点：

• 1、这种扩展接口的方式是最常见的用法，继承jparepository接口后，立马拥有基础的curd功能
• 2、还可以通过特定的方法名做解析查询，这个可以算spring data jpa的最特殊的特性了。而且主流的ide对这种使用方式都有比较好的自动化支持，在输入要解析的方法名时会给出提示。
• 3、可以非常方便的以注解的形式支持hql和原生sql

缺陷：

• 1、复杂的分页查询支持不好

缺陷就一条，这种扩展接口的方式要实现复杂的分页查询，有两种方式,而且这两种方式代码写起来都不怎么优雅，而且会把大量的条件拼接逻辑写在调用查询的service层。

• 第一种、实例查询(example query)方式:

上面代码实现的语义是模糊查询templatename等于"kl"的记录并分页，乍一看这个代码还过得去哈，其实当查询的条件多一点，这种代码就会变得又臭又长，而且只支持基础的字符串类型的字段查询，如果查询条件有时间筛选的话就不支持了，在复杂点多表关联的话就更gg了，所以这种方式不合格直接上黑名单了。

• 第二种、继承jpaspecificationexecutor方式：

jpa 2引入了一个标准api，您可以使用它来以编程方式构建查询。spring data jpa提供了使用jpa标准api定义此类规范的api。这种方式首先需要继承jpaspecificationexecutor接口，下面我们用这种方式实现和上面相同语义的查询：

这种方式显然更对味口了吧，而且也支持复杂的查询条件拼接，比如日期等。唯一的缺憾是领域对象的属性字符串需要手写了，而且接口只会提供findall(@nullable specificationspec, pageable pageable)方法，各种复杂查询逻辑拼接都要写在service层。对于架构分层思想流行了这么多年外加强迫症的人来说实在是不能忍，如果单独封装一个dao类编写复杂的查询又显的有点多余和臃肿

spring data jpa最佳实践

在详细介绍最佳实践前，先思考和了解一个东西，spring data jpa是怎么做到继承一个接口就能实现各种复杂查询的呢？这里其实是一个典型的代理模式的应用，只要继承了最底层的repository接口，在应用启动时就会帮你生成一个代理实例，而真正的目标类才是最终执行查询的类，这个类就是:simplejparepository,它实现了jparepository、jpaspecificationexecutor的所有接口，所以只要基于simplejparepository定制repository基类，就能拥有继承接口一样的查询功能，而且可以在实现类里编写复杂的查询方法了。

一、继承simplejparepository实现类

构造一个simplejparepository实例，只需要一个领域对象的类型，和entitymanager 实例即可，entitymanager在spring的上下文中已经有了，会自动注入。领域对象类型在具体的实现类中注入即可。如：

通过继承basejparepository，使sendlogjparepository拥有了jparepository、jpaspecificationexecutor接口中定义的所有方法功能。而且基于抽象基类中entitymanager实例，也可以非常方便的编写hql和原生sql查询等。最赏心悦目的是不仅拥有了最基本的curd等功能，而且超复杂的分页查询也不分家了。只是jpaspecification查询方式还不是特别出彩，下面继续最佳实践

二、集成querydsl结构化查询

querydsl是一个框架，可通过其流畅的api来构造静态类型的类似sql的查询。这是spring data jpa文档中对querydsl的描述。spring data jpa对querydsl的扩展支持的比较好，基本可以无缝集成使用。querydsl定义了一套和jpaspecification类似的接口，使用方式上也类似，由于querydsl多了一个maven插件，可以在编译期间生成领域对象操作实体，所以在拼接复杂的查询条件时相比较jpaspecification显的更灵活好用，特别在关联到多表查询的时候。下面看下怎么集成：

1、快速集成

因为之前有写过最简单的querydsl集成方式，所以这里就不在赘述了，具体参见《querydsl结构化查询之jpa》,

2、丰富basejparepository基类

在basejparepository基类中新增了querydsljpapredicateexecutor实例，它是spring data jpa基于querydsl的一个实现。用来执行querydsl的predicate相关查询。集成querydsl后，复杂分页查询的画风就变的更加清爽了，如：

到目前为止，实现相同的复杂分页查询，代码已经非常的清爽和优雅了，在复杂的查询在这种模式下也变的非常的清晰。但是，这还不是十分完美的。还有两个问题需要解决下：

• querydsljpapredicateexecutor实现的方法不支持分页查询同时又有字段排序。下面是它的接口定义，可以看到，要么分页查询一步到位但是没有排序，要么排序查询返回list列表自己封装分页。

• 复杂的多表关联查询querydsljpapredicateexecutor不支持

3、最终的basejparepository形态

spring data jpa对querdsl的支持毕竟有限，但是querydsl是有这种功能的，像上面的场景就需要特别处理了。最终改造的basejparepository如下：

新增了findall(predicate predicate, pageable pageable, orderspecifier... orders)方法，用于支持复杂分页查询的同时又有字段排序的查询场景。其次的改动是引入了jpaqueryfactory实例，用于多表关联的复杂查询。使用方式如下：

三、集成p6spy打印执行的sql

上面的功能以及十分完美了，但是谈到最佳实践似乎少了一个打印sql的功能。在使用jpa的结构化语义构建复杂查询时，经常会因为各种原因导致查询的结果集不是自己想要的，但是又没法排查，因为不知道最终执行的sql是怎么样的。spring data jpa也有打印sql的功能，但是比较鸡肋，它打印的是没有替换查询参数的sql，没法直接复制执行。所以这里推荐一个工具p6spy，p6spy是一个打印最终执行sql的工具，而且可以记录sql的执行耗时。使用起来也比较方便，简单三步集成：

1、引入依赖

 2、修改数据源链接字符串

 3、添加配置spy.propertis配置

这个是最简化的自定义打印的配置，更多配置可参考：https://p6spy.readthedocs.io/en/latest/configandusage.html

结语

最后的basejparepository功能上基本满足了所有的查询需求，又做了基础查询和复杂查询的不分离，不至于把大量的复杂查询拼接逻辑写到service层，或者是新建的复杂查询类里。彻底解决了文首提出的那些问题。基于querydsl的复杂查询代码逻辑清晰，结构优雅，极力推荐使用。最后，在安利下p6spy，一个非常实用的打印sql的工具，可以帮助排查分析jpa最终生成执行的sql语句,其打印的sql语句可以直接复制到mysql管理工具中执行的。

以上就是spring data jpa框架最佳实践示例的详细内容，更多关于spring data jpa框架的资料请关注其它相关文章！