Bean Searcher为啥这么牛逼？任何复杂查询一行代码都可以搞定！

最新推荐文章于 2024-10-23 14:18:40 发布

公众号-老炮说Java

最新推荐文章于 2024-10-23 14:18:40 发布

阅读量777

点赞数 1

文章标签： mybatis java 开发语言

原文链接：https://mp.weixin.qq.com/s?__biz=MzAxNDMwMTMwMw==&mid=2247549921&idx=2&sn=4a7b9068867dd3e967a28c184dad43cf&chksm=9b9722f9ace0abef40d23e3e3cafb97ff82679a9c9d0734c6899efbe9dcb35a31ca5b342f851&scene=126&sessionid=0

版权

Bean Searcher 号称任何复杂的查询都可以一行代码搞定，但 Mybatis Plus 似乎也有类似的动态查询功能，它们有怎样的区别呢？

区别一（基本）

Mybatis Plus 依赖 MyBatis, 功能 CRUD 都有，而 Bean Seracher 不依赖任何 ORM，只专注高级查询。

只有使用 MyBatis 的项目才会用 Mybatis Plus，而使用 Hibernate，Data Jdbc 等其它 ORM 的人则无法使用 Mybatis Plus。但是这些项目都可以使用 Bean Searcher（可与任何 ORM 配合使用，也可单独使用）。

使用 Mybatis Plus 需要编写实体类和 Mapper 接口，而 Bean Searcher 只需编写实体类，无需编写任何接口。

这个区别意义其实不大，因为如果你用 Mybatis Plus，在增删改的时候还是需要定义 Mapper 接口。

区别二（高级查询）

Mybatis Plus 的字段运算符是静态的，而 Bean Searcher 的是动态的。

字段运算符指的是某字段参与条件时用的是 =、> 亦或是 like 这些条件类型。
不只 Mybatis Plus，一般的传统 ORM 的字段运算符都是静态的，包括 Hibernate、Spring data jdbc、JOOQ 等。

下面举例说明。对于只有三个字段的简单实体类：

public class User {    private long id;    private String name;    private int age;    // 省略 Getter Setter}

1）使用 MyBatis Plus 查询：

依赖：

implementation 'com.baomidou:mybatis-plus-boot-starter:3.5.2

首先要写一个 Mapper 接口：

public interface UserMapper extends BaseMapper<User> {
}

然后在 Controller 里写查询接口：

@RestController@RequestMapping("/user")public class UserController {    @Autowired
    private UserMapper userMapper;    @GetMapping("/mp")
    public List<User> mp(User user) {        return userMapper.selectList(new QueryWrapper<>(user));
    }
    
}

此时这个接口可以支持三个检索参数，id, name, age，例如：

GET /user/mp? name=Jack 查询 name 等于 Jack 的数据
GET /user/mp? age=20 查询 age 等于 20 的数据

但是他们所能表达的关系都是等于，如果你还想查询 age > 20 的数据，则无能为力了，除非在实体类的 age 字段上加上一条注解：

@TableField(condition = "%s>#{%s}")private int age;

但加了注解后，age 就只能表达大于的关系了，不再可以表达等于了。所以说，MyBatit Plus 的字段运算符是静态的，不能由参数动态指定。

当然我们可以在 Controller 里根据参数调用 QueryWrapper 的不同方法让它支持，但这样代码就不只一行了，检索的需求越复杂，需要编写的代码就越多了。

2）使用 Bean Searcher 查询：

依赖：

implementation 'com.ejlchina:bean-searcher-boot-starter:3.7.1'

不用编写任何接口，复用同一个实体类，直接进行查询：

@RestController@RequestMapping("/user")public class UserController {    @Autowired
    private BeanSearcher beanSearcher;    @GetMapping("/bs")
    public List<User> bs(@RequestParam Map<String, Object> params) {        // 你是否对入参 Map 有偏见？如果有，请耐心往下看，有方案
        return beanSearcher.searchList(User.class, params);
    }
    
}

此时这个接口可以支持的检索参数就非常多了：

GET /user/bs? name=Jack 查询 name 等于 Jack 的数据
GET /user/bs? name=Jack & name-ic=true 查询 name 等于 Jack 时忽略大小写
GET /user/bs? name=Jack & name-op=ct 查询 name 包含 Jack 的数据
GET /user/bs? age=20 查询 age 等于 20 的数据
GET /user/bs? age=20 & age-op=gt 查询 age 大于 20 的数据
等等...

可以看出，Bean Searcher 对每个字段使用的运算符都可以由参数指定，它们是动态的。

无论查询需求简单还是复杂，Controller 里都只需一行代码。
参数 xxx-op 可以传哪些值？参阅这里：bs.zhxu.cn/guide/lates…

看到这里，如果看的明白，应该有一半的读者开始感慨：好家伙，这不是把后端组装查询条件的过程都甩给了前端？谁用了这个框架，不会被前端打死吗？

哈哈，我是不是道出了你现在心里的想法？如果你真的如此想，请仔细回看我们正在讨论的主题：【高级查询】！如果不能理解什么是高级查询，我再贴个图助你思考：

当然也并不是所有的检索需求都如此复杂，当前端不需要控制检索方式时，xxx-op 参数可以省略，省略时，默认表达的是等于，如果你想表达其它方式，只需一个注解即可，例如：

@DbField(onlyOn = GreaterThan.class)private int age;

这时，当前端只传一个 age 参数时，执行的 SQL 条件就是 age > ? 了，并且即使前端多传一个 age-op 参数，也不再起作用了。

这其实是条件约束，下文会继续讲到。

区别三（逻辑分组）

就上文所例的代码，除却运算符动静的区别，Mybatis Plus 对接收到的参数生成的条件都是且的关系，而 Bean Searcher 默认也是且，但支持逻辑分组。

再举例说明，假设查询条件为：

( name = Jack 并且 age = 20 ) 或者 ( age = 30 )

此时，MyBatis Plus 的一行代码就无能为力了，但 Bean Searcher 的一行代码仍然管用，只需这样传参即可：

GET /user/bs? a.name=Jack & a.age=20 & b.age=30 & gexpr=a|b

这里 Bean Searcher 将参数分为 a, b 两组，并用新参数 gexpr 来表达这两组之间的关系（a 或 b）。

实际传参时gexpr的值需要 URLEncode 编码一下: URLEncode('a|b') => 'a%7Cb'，因为 HTTP 规定参数在 URL 上不可以出现 | 这种特殊字符。当然如果你喜欢 POST, 可以将它放在报文体里。

什么场景下适合使用此功能？当遇见类似下图中的需求时，它将助你一招制敌：

分组功能非常强大，但如此复杂的检索需求也确实罕见，这里不再细述，详情可阅：bs.zhxu.cn/guide/lates…

区别四（多表联查）

在不写 SQL 的情况下，Mybatis Plus 的动态查询仅限于单表，而 Bean Searcher 单表和多表都支持的一样好。

这也是很重要的一点区别，因为大多数高级查询场景都是需要联表的。

当然有些人坚持用单表做查询，为了避免联表，从而在主表中冗余了很多字段，这不仅造成了数据库存储空间压力急剧增加，还让项目更加难以维护。因为源数据一但变化，你必须同时更新这些冗余的字段，只要漏了一处，BUG 就跳出来了。

还是举个例子，某订单列表需要展示订单号，订单金额，店铺名，买家名等信息，用 Bean Searcher 实体类可以这么写：

@SearchBean(
    tables = "order o, shop s, user u",  // 三表关联
    joinCond = "o.shop_id = s.id and o.buyer_id = u.id",  // 关联关系
    autoMapTo = "o"  // 未被 @DbField 注解的字段都映射到 order 表
)public class OrderVO {    private long id;         // 订单ID   o.id
    private String orderNo;  // 订单号   o.order_no
    private long amount;     // 订单金额 o.amount
    @DbField("s.name")
    private String shop;     // 店铺名   s.name
    @DbField("u.name")
    private String buyer;    // 买家名   u.name
    // 省略 Getter Setter}

有心的同学会注意到，这个实体类的命名并不是 Order, 而是 OrderVO。这里只是一个建议的命名，因为它是本质上就是一个 VO（View Object），作用只是一个视图实体类，所以建议将它和普通的单表实体类放在不同的 package 下（这只是一个规范）。

然后我们的 Controller 中仍然只需一行代码：

@RestController@RequestMapping("/order")public class OrderController {    @Autowired
    private BeanSearcher beanSearcher;    @GetMapping("/index")
    public SearchResult<OrderVO> index(@RequestParam Map<String, Object> params) {        // search 方法同时会返回满足条件的总条数
        return beanSearcher.search(OrderVO.class, params);
    }

}

这就实现了一个支持高级查询的订单接口，它同样支持在上文区别二与区别三中所展示的各种检索方式。

从本例可以看出，Bean Searcher 的检索结果是 VO 对象，而非普通的单表实体类（DTO），这省去了 DTO 向 VO 的转换过程，它可以直接返回给前端。

区别五（使用场景）

在事务性的接口用推荐使用 MyBatis Plus, 非事务的检索接口中推荐使用 Bean Searcher

例如创建订单接口，在这个接口内部同样有很多查询，比如你需要查询店铺的是否已经打烊，商品的库存是否还足够等，这些查询场景，推荐依然使用原有的 MyBatis Plus 或其它 ORM 就好，不必再用 Bean Seracher 了。
再如订单列表接口，纯查询，可能需要分页、排序、过滤等功能，此时就可用 Bean Seracher 了。

网友疑问

1）这貌似开放很大的检索能力，风险可控吗?

Bean Searcher 默认对实体类中的每个字段都支持了很多种检索方式，但是我们也可以对它进行约束。

条件约束

例如，User 实体类的 name 字段只允许精确匹配与后模糊查询，则在 name 字段上添加一个注解即可：

@DbField(onlyOn = {Equal.class, StartWith.class})private String name;

再如：不允许 age 字段参与 where 条件，则可以：

@DbField(conditional = false)private int age;

参考：bs.zhxu.cn/guide/lates…

排序约束

Bean Searcher 默认允许按所有字段排序，但可以在实体类里进行约束。例如，只允许按 age 字段降序排序：

@SearchBean(orderBy = "age desc", sortType = SortType.ONLY_ENTITY)
public class User {
    // ...
}

或者，禁止使用排序：

@SearchBean(sortType = SortType.ONLY_ENTITY)
public class User {
    // ...
}

参考：bs.zhxu.cn/guide/lates…

2）使用 Bean Searcher 后 Controller 的入参必须是 Map 类型?

答：这并不是必须的，只是 Bean Searcher 的检索方法接受这个类型的参数而已。如果你在 Controller 入参那里用一个 POJO 来接收也是可以的，只需要再用一个工具类把它转换为 Map 即可，只不过平白多写了一个类而已，例如：

@GetMapping("/bs")public List<User> bs(UserQuery query) {    // 将 UserQuery 对象转换为 Map 再传入进行检索
    return beanSearcher.searchList(User.class, Utils.toMap(query));
}

这里为什么不直接使用 User 实体类来接收呢？因为 Bean Searcher 默认支持很多参数，而原有的 User 实体类中的字段不够多，用它来接收的话会有很多参数接收不到。如果咱们的检索需求比较简单，不需要前端指定那些参数，则可以直接使用 User 实体类来接收。

这里的 UserQuery 可以这么定义：

// 继承 User 里的字段public class UserQuery extends User {    // 附加：排序参数
    private String order;    private String sort;    // 附加：分页参数
    private Integer page;    private Integer size;    // 附加：字段衍生参数
    private String id_op;   // 由于字段命名不能有中划线，这里有下划线替代
    private String name_op; // 前端传参的时候就不能传 name-op，而是 name_op 了
    private String name_ic;    private String age_op;    // 省略其它附加字段...
    
    // 省略 Getter Setter 方法}

然后 Utils 工具类的 toMap 方法可以这样写（这个工具类是通用的）：

public static Map<String, Object> toMap(Object bean) {
    Map<String, Object> map = new HashMap<>();
    Class<?> beanClass = bean.getClass();    while (beanClass != Object.class) {        for (Field field : beanClass.getDeclaredFields()) {
            field.setAccessible(true);            try {                // 将下划线转换为中划线
                Strubg name = field.getName().replace('_', '-');
                map.put(name, field.get(bean));
            } catch (IllegalAccessException e) {                throw new RuntimeException(e);
            }
        }
        beanClass = beanClass.getSuperclass();
    }    return map;
}

这样就可以了，该接口依然可以支持很多种检索方式：

GET /user/bs? name=Jack 查询 name 等于 Jack 的数据
GET /user/bs? name=Jack & name_ic=true 查询 name 等于 Jack 时忽略大小写
GET /user/bs? name=Jack & name_op=ct 查询 name 包含 Jack 的数据
GET /user/bs? age=20 查询 age 等于 20 的数据
GET /user/bs? age=20 & age_op=gt 查询 age 大于 20 的数据
等等...

注意使用参数是 name_op，不再是 name-op 了

以上的方式应该满足了一些强迫症患者的期望，但是这样的代价是多写一个 UserQuery 类，这不禁让我们细想：这样做值得吗？

当然，写成这样是有一些好处的：

便于参数校验
便于生成接口文档

但是：

这是一个非事务性的检索接口，参数校验真的那么必要吗？本来就可以无参请求，参数传错了系统自动忽略它是不是也可以？
如果了解了 Bean Searcher 参数规则，是不是不用这个 UserQuery 类也可以生成文档，或者在文档中一句话概括该接口是 Bean Searcher 检索接口，请按照规则传递参数，是不是也行呢？

所以，我的建议是：一切以真实需求为准则，不要为了规范而去规范，莫名徒增代码。

看到这里，你可能已经在心里准备了一大堆的话想要反驳我，别急，我们先回顾一下前面的 [多表联查] 章节所提到的：

Bean Searcher 中的实体类（SearchBean），实际上是一个可以直接与 DB 有跨表映射关系的 VO（View Ojbect），它代表一种检索业务，在概念上它与传统 ORM 的实体类（Entity）或域类（Domain）有着本质的区别！

这一句话，道出了 Bean Searcher 的灵魂。它看似简单，实则难以悟透。如果您不是那种千古罕见先天通灵的奇才，强烈建议阅读官方文档的介绍 > 设计哲学章节，那里有对这一句话的详细解释。

3）想手动添加或修改参数，只能向 `Map` 里 `put` 吗？有没有优雅点写法？

答：当然有。Bean Searcher 提供了一个参数构建器，可让后端人员想手动添加或修改检索参数时使用。例如：

@GetMapping("/bs")public List<User> bs(@RequestParam Map<String, Object> params) {
    params = MapUtils.builder(params)  // 在原有参数基础之上
        .field(User::getAge, 20, 30).op(Between.class) // 添加一个年龄区间条件
        .field(User::getName).op(StartWith.class) // 修改 name 字段的运算符为 StartWith，参数值还是用前端传来的参数
        .build();    return beanSearcher.searchList(User.class, params);
}

4）前端乱传参数的话，存在 SQL 注入风险吗？

答：不存在的，Bean Searcher 是一个只读 ORM，它也存在对象关系映射，所传参数都是实体类内定义的 Java 属性名，而非数据库表里的字段名（当前端传递实体类未定义的字段参数时，会被自动忽略）。

也可以说：检索参数与数据库表是解耦的。

5）可以随意传参，会让用户获取本不该看到的数据吗？

答：不会的，因为用户可获取数据最多的请求就是无参请求，用户尝试的任何参数，都只会缩小数据范围，不可能扩大。

如果想做数据权限，根据不同的用户返回不同的数据：可在参数过滤器里为权限字段统一注入条件（前提是实体类中得有一个数据权限字段，可以在基类中定义）。

6）效率虽有提高，但性能如何呢？

前段时间又不少朋友看了这篇文章私下问我 Bean Searcher 的性能如何，这个周末我就在家做了下对比测试，结果如下：

比 Spring Data Jdbc 高 5 ~ 10 倍
比 Spring Data JPA 高 2 ~ 3 倍
比原生 MyBatis 高 1 ~ 2 倍
比 MyBatis Plus 高 2 ~ 5 倍

完整报告：

github.com/ejlchina/be…
gitee.com/troyzhxu/be…

以上测试是基于 H2 内存数据库进行

测试源码地址，大家可自行测试对比：

github.com/ejlchina/be…
gitee.com/troyzhxu/be…

7）支持哪些数据库呢？

只要支持正常的 SQL 语法，都是支持的，另外 Bean Searcher 内置了四个方言实现：

分页语法和 MySQL 一样的数据库，默认支持
分页语法和 PostgreSql 一样的数据库，选用 PostgreSql 方言即可
分页语法和 Oracle 一样的数据库，选用 Oracle 方言即可
分页语法和 SqlServer（v2012+）一样的数据库，选用 SqlServer 方言即可

如果分页语法独创的，自定义一个方言，只需实现一个方法即可，参考：高级 > SQL 方言章节。

总结

上文所述的各种区别，并不是说 MyBatis Plus 和 Bean Searcher 哪个好哪个不好，而是它们专注的领域确实不一样（BS 也不会替代 MP）。

Bean Searcher 在刚诞生的时候是专门用来处理那种特别复杂的检索需求（如上文中的例图所示），一般都用在管理后台系统里。
但用着用着，我们发现，对检索需求没那么复杂的普通分页查询接口，Bean Searcher 也非常好用。
代码写起来比用传统的 ORM 要简洁的多，只需一个实体类和 Controller 里的几行代码，Service 和 Dao 什么的全都消失了，而且它返回的结果就是 VO, 也不需要再做进一步的转换了，可以直接返回给前端。

在项目中配合使用它们，事务中使用 MyBatis Plus，列表检索场景使用 Bean Searcher，你将如虎添翼。

实际上，在旧项目中集成 Bean Searcher 更加容易，已有的单表实体类都能直接复用，而多表关联的 VO 对象类也只需添加相应注解即可拥有强大的检索能力。
无论项目原来 ORM 用的是 MyBatis, MP, 还是 Hibernate，Data Jdbc 等，也无论 Web 框架是 Spring Boot, Spring MVC 还是 Grails 或 Jfinal 等，只要是 java 项目, 都可以用它，为系统赋能高级查询。

https://blog.csdn.net/qq_31905135/article/details/130724938

精品推荐

1.公司入职一个阿里大佬，30万条数据插入 MySQL 仅用13秒，给大家看看核心代码！
2.SpringBoot + 规则引擎 URule，真的太强悍了！
3.代码精简10倍，责任链模式yyds
4.3个月的ChatGPT使用，帮我生成95%的代码，我已离不开他！
5.新来个技术总监：发现谁再用 delete 删数据直接开除！
6.5年开发，不会循环删除 List 中的元素，有这么难么？
7.字节二面：一千万的数据，你是怎么查询的？
8.Guava的这些骚操作，让我的代码量减少了60%