SpringBoot+Querydsl 框架，大大简化复杂查询操作

谁践踏了优雅 2023-09-29 16:11 26阅读 0赞

## 概述 ##

本篇博客主要将介绍的是利用spring query dsl框架实现的服务端查询解析和实现介绍。

查询功能是在各种应用程序里面都有应用，且非常重要的功能。用户直接使用的查询功能往往是在我们做好的UI界面上进行查询，UI会将查询请求发给查询实现的服务器，或者专门负责实现查询的一个组件。市场上有专门做查询的框架，其中比较出名，应用也比较广泛的是elasticsearch。

## 定义查询请求 ##

对于服务端来说，前端UI发送过来的查询请求必然是按一定规则组织起来的，这样的规则后端必须能够支持和解析。换一种说法就是服务调用者和服务发布者之间需要遵循同一个规范才可以。百度的UI查询是这样定义的：

![8699885830d6f74c2cfe787098507f95.png][]

在上图中加了蓝色下划线的地方即为我们在百度当中搜索的字符串内容，可以发现，百度的实现是将搜索的内容当做了http请求的url的参数来处理的，用了一个q作为key，q后面的内容就是所查询的内容。

google的实现是类似的，如下图所示：

![dc6b7f350c98767055e8d26c4316cffb.png][]

对于google和百度这样的只有一个搜索框的查询界面，这样处理是比较合理的，也不是整个查询实现最关键的部分。更为关键的是后续服务器将这个查询内容进行了怎样的处理。对于别的一些产品来说，可能需要对某些关键字进行单独的查询，这个时候肯定就不是一个搜索框能个满足的需求了。

总的来说，我们可以有如下的方式来组织一个查询

## google-like查询 ##

这种查询典型的应用是一个查询框，什么都可以查的情形，例如google和百度。对于这样的查询需求来说,在构建查询请求时只需将查询的内容放在http请求的的参数里面即可。

这样的查询解析是非常方便的，难度和需要考虑得事情在于要讲查询的内容放到哪些地方去查询。从数据库的层面来说就是要去哪些数据库的哪些表去查询。

## 特定字段的类sql查询 ##

这种查询是指定某个字段，然后采用类似于sql语句的写法进行查询，各种查询条件以一定的形式组织在一起，发给服务器进行解析。这样的查询对服务器解析查询的能力要求更高，它提供了一些更加具体的查询条件。

例如我们以冒号表示等于,则一个查询字符串的形式是:

name:bill

这个查询的意思就是查询名字name等于bill的记录。

我们也可以将多个条件拼接在一起，让他们直接用逻辑关系组合在一起，例如或者和并且的逻辑关系。例如：

name:bill AND city:LA

或者下面这种或者的关系：

name:bill OR city:LA

上面的查询语句意味着我们的前后台要定义一套自己的查询逻辑和架构，并且解析它，并将它转换为正确的查询。若我们想实现灵活的查询，则上面的查询语句在符合规则的前提下应当是可以自由组合的。怎么做取决于我们的实际需求。如果一个写死的查询关键字就能满足我们的需求，则在当前那个时期自然也是合理的。

但是从灵活性角度，技术角度，实现成灵活的可解析的，显然是我们更想要的功能。最灵活的当然就是sql语句能支持怎样的查询，我们都能支持对应的查询写法，但是这对服务器的解析逻辑就有了更加高的要求，尤其是当主表子表混在一起查询之后，会更加复杂

## 使用Spring Data Querydsl ##

什么是Querydsl呢？Querydsl是一个框架，它可以通过它提供的的API帮助我们构建静态类型的SQL-like查询，也就是在上面我们提到的组织查询方式。可以通过诸如Querydsl之类的流畅API构造查询。

**Querydsl是出于以类型安全的方式维护HQL查询的需要而诞生的。** HQL查询的增量构造需要String连接，这导致难以阅读的代码。通过纯字符串对域类型和属性的不安全引用是基于字符串的HQL构造的另一个问题。

随着域模型的不断变化，类型安全性在软件开发中带来了巨大的好处。域更改直接反映在查询中，而查询构造中的自动完成功能使查询构造更快，更安全。

用于Hibernate的HQL是Querydsl的第一个目标语言，如今querydsl支持JPA，JDO，JDBC，Lucene，Hibernate Search，MongoDB，Collections和RDFBean作为它的后端。

> 其官方网站在这里：http://querydsl.com/

Querydsl和spring有什么关系呢？几个Spring Data的模块通过QuerydslPredicateExecutor提供了与Querydsl的集成，如以下示例所示：

public interface QuerydslPredicateExecutor<T> {
    //查找并返回与Predicate匹配的单个entity。
      Optional<T> findById(Predicate predicate);  
    //查找并返回与Predicate匹配的所有entity
      Iterable<T> findAll(Predicate predicate);   
    //返回与Predicate匹配的数量。
      long count(Predicate predicate);            
    //返回是否存在与Predicate匹配的entity。
      boolean exists(Predicate predicate);        
     
      // … more functionality omitted.
    }

Predicate就是我们需要传入的一个查询的抽象。

在spring当中使用Querydsl，只需要在spring的repository接口继承QuerydslPredicateExecutor，如以下示例所示:

interface UserRepository extends CrudRepository<User, Long>, QuerydslPredicateExecutor<User> {
    }

在定义了上面的这个接口之后，我们就可以使用Querydsl Predicate编写type-safe的查询，如以下示例所示：

Predicate predicate = user.firstname.equals("dave")
     .and(user.lastname.startsWith("mathews"));
     
    userRepository.findAll(predicate);

上面的代码构建出的predicate体现在sql语句里的话就是这样的: where firstname = 'dave' and lastname ='mathews%'。这就是所谓的类sql的查询，用起来非常的直观。

因此，我们可以将我们接收到的查询请求，转化为对应的predicte，且从技术上讲，只要predict支持的查询拼接我们都能支持，难点只在于如何解析查询请求，以及如何将他们转换为对应的predicate.

## 利用Spring Query DSL实现动态查询 ##

下面是使用spring和Querydsl实现动态查询的一个例子.

现在假设我们有Model类如下:

public class Student {
     
        private String id;
     
        private String gender;
     
        private String firstName;
     
        private String lastName;
     
        private Date createdAt;
      
        private Boolean isGraduated;
     
    }

我们希望可以实现该类所有字段直接自由组合进行查询，且可以按照与和或的逻辑进行查询。且我们约定用冒号表示等于，例如:

firstname:li AND lastname:hua
     
    firstname:li OR lastname:hua
     
    firstname:li AND lastname:hua AND gender:male

上面的查询都比较清晰，解析不会有太大难度，下面我们来看这样一个查询：

firstname:li OR lastname:hua AND gender:male

这个查询的问题在于作为逻辑与的gender查询，到底是只和前面一个条件进行与操作，还是与前面两个条件一起进行一个与操作，显然与的条件往往是作为filter的功能出现的。

因此我们应当将其看作整个其他条件的与操作，因此我们需要先将前面的条在组合在一起，例如，我们可以使用括号表示这个逻辑，那么查询就会变成:

(firstname:li AND lastname:hua) AND gender:male

[8699885830d6f74c2cfe787098507f95.png]: https://img-blog.csdnimg.cn/img_convert/8699885830d6f74c2cfe787098507f95.png
[dc6b7f350c98767055e8d26c4316cffb.png]: https://img-blog.csdnimg.cn/img_convert/dc6b7f350c98767055e8d26c4316cffb.png