这样写代码，比直接使用 MyBatis 效率提高了 100 倍

2021-11-07  本文已影响0人  Troy_Zhou
image.png

下篇：最近火起的 Bean Searcher 与 MyBatis Plus 倒底有啥区别？

对一个 Java 后端程序员来说，MyBatis、Hibernate、Data Jdbc 等都是我们常用的 ORM 框架。它们有时候很好用，比如简单的 CRUD，事务的支持都非常棒。但有时候用起来也非常繁琐，比如接下来我们要聊到的一个常见的开发需求，而对这类需求，本文会给出一个比直接使用这些 ORM 开发效率至少会提高 100 倍的方法（绝无夸张）。

image.png

首先数据库有两张表

用户表（user）：（简单起见，假设只有 4 个字段）

字段名 类型 含义
id bitint 用户 ID
name varchar(45) 用户名
age int 年龄
role_id int 角色 ID

角色表（role）：（简单起见，假设只有 2 个字段）

字段名 类型 含义
id int 角色 ID
name varchar(45) 角色名

接下来我们要实现一个用户查询的功能

这个查询有点复杂，它的要求如下：

后端接口该怎么写呢？

试想一下，对于这种要求的查询，后端接口里的代码如果用 MyBatis、Hibernate、Data Jdbc 直接来写的话，100 行代码 能实现吗？

反正我是没这个信心，算了，我还是直接坦白，面对这种需求后端如何 只用一行代码搞定 吧（有兴趣的同学可以 MyBatis 等写个试试，最后可以对比一下）

手把手：只一行代码实现以上需求

首先，重点人物出场啦：Bean Searcher, 它是一个专注于 高级查询 的 只读 ORM，对于这种列表检索，无论简单还是复杂，统统一行代码搞定！而且它还非常轻量，且无第三方依赖（可与任何其它 ORM 在同一项目中使用）。

假设我们项目使用的框架是 Spring Boot（当然 Bean Searcher 对框架没有要求，但在 Spring Boot 中使用更加方便）

添加依赖

Maven ：

<dependency>
    <groupId>com.ejlchina</groupId>
    <artifactId>bean-searcher-boot-starter</artifactId>
    <version>3.6.0</version>
</dependency>

Gradle ：

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

然后写个实体类来承载查询的结果

@SearchBean(tables="user u, role r", joinCond="u.role_id = r.id", autoMapTo="u") 
public class User {

    private Long id;        // 用户ID（u.id）
    private String name;    // 用户名（u.name）
    private int age;        // 年龄（u.age）
    private int roleId;     // 角色ID（u.role_id）
    @DbField("r.name")      // 指明这个属性来自 role 表的 name 字段
    private String role;        // 角色名（r.name）

    // Getter and Setter ...
}

注意：这个实体类映射到了两张表，并且它是可以直接返回给前端的

接着就可以写用户查询接口了

接口路径就叫 /user/index 吧：

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private MapSearcher mapSearcher;  // 注入检索器（由 bean-searcher-boot-starter 提供）

    @GetMapping("/index")
    public SearchResult<Map<String, Object>> index(HttpServletRequest request) {
        // 这里咱们只写一行代码
        return mapSearcher.search(User.class, MapUtils.flat(request.getParameterMap()));
    }

}

上述代码中的 MapUtils 是 Bean Searcher 提供的一个工具类，MapUtils.flat(request.getParameterMap()) 只是为了把前端传来的请求参数统一收集起来，然后剩下的，就全部交给 MapSearcher 检索器了。

这样就完了？那我们来测一下这个接口，看看效果吧

（1）无参请求

{
    "dataList": [           // 用户列表，默认返回第 0 页，默认分页大小为 15 （可配置）
        { "id": 1, "name": "Jack", "age": 25, "roleId": 1, "role": "普通用户" },
        { "id": 2, "name": "Tom", "age": 26, "roleId": 1, "role": "普通用户" },
        ...
    ],
    "totalCount": 100       // 用户总数
}

（2）分页请求（page | size）

参数名 size 和 page 可自定义， page 默认从 0 开始，同样可自定义，并且可与其它参数组合使用

（3）数据排序（sort | order）

参数名 sort 和 order 可自定义，可与其它参数组合使用

（4）指定（排除）字段（onlySelect | selectExclude）

{
    "dataList": [           // 用户列表，默认返回第 0 页（只包含 id,name,role 字段）
        { "id": 1, "name": "Jack", "role": "普通用户" },
        { "id": 2, "name": "Tom", "role": "普通用户" },
        ...
    ],
    "totalCount": 100       // 用户总数
}

参数名 onlySelect 和 selectExclude 可自定义，可与其它参数组合使用

（5）字段过滤（op = eq）

参数 age-op = eq 表示 age 的 字段运算符 是 eq（Equal 的缩写），表示参数 age 与参数值 20 之间的关系是 Equal，由于 Equal 是一个默认的关系，所以 age-op = eq 也可以省略
参数名 age-op 的后缀 -op 可自定义，且可与其它字段参数 和 上文所列的参数（分页、排序、指定字段）组合使用，下文所列的字段参数也是一样，不再复述。

（6）字段过滤（op = ne）

（7）字段过滤（op = ge）

（8）字段过滤（op = le）

（9）字段过滤（op = gt）

（10）字段过滤（op = lt）

（11）字段过滤（op = bt）

参数 age-0 = 20 表示 age 的第 0 个参数值是 20。上述提到的 age = 20 实际上是 age-0 = 20 的简写形式。另：参数名 age-0 与 age-1 中的连字符 - 可自定义。

（12）字段过滤（op = il）

（13）字段过滤（op = ct）

（14）字段过滤（op = sw）

（15）字段过滤（op = ew）

（16）忽略大小写（ic = true）

参数名 name-ic 中的后缀 -ic 可自定义，该参数可与其它的参数组合使用，比如这里检索的是 name 等于 Jack 时忽略大小写，但同样适用于检索 name 以 Jack 开头或结尾时忽略大小写。

还支持更多的检索方式，这里不再一一举例，欲了解更多请移步这里： https://searcher.ejlchina.com/guide/latest/params.html#%E5%AD%97%E6%AE%B5%E8%BF%90%E7%AE%97%E7%AC%A6

当然，以上各种条件都可以组合，例如

查询 name 以 Jack (忽略大小写) 开头，且 roleId = 1，结果以 id 字段排序，每页加载 10 条，查询第 2 页：

实际上，Bean Searcher 还支持更多的检索方式（甚至可以自定义），这里就不再一一列举了。

OK，效果看完了，/user/index 接口里我们确实只写了一行代码，它便可以支持这么多种的检索方式，有没有觉得现在 你写的一行代码 就可以 干过别人的一百行 呢？

image.png

Bean Searcher

本例中，我们只使用了 Bean Searcher 提供的 MapSearcher 检索器的一个检索方法，其实，它还有很多检索方法。

检索方法

MapSearcher 与 BeanSearcher

另外，Bean Searcher 除了提供了 MapSearcher 检索器外，还提供了 BeanSearcher 检索器，它同样拥有 MapSearcher 所有的方法，只是它返回的单条数据不是 Map，而是一个 泛型 对象。

参数构建工具

另外，如果你是在 Service 里使用 Bean Searcher，那么直接使用 Map<String, Object> 类型的参数可能不太优雅，为此， Bean Searcher 特意提供了一个参数构建工具。

例如，同样查询 name 以 Jack (忽略大小写) 开头，且 roleId = 1，结果以 id 字段排序，每页加载 10 条，加载第 2 页，使用参数构建器，代码可以这么写：

Map<String, Object> params = MapUtils.builder()
        .field(User::getName, "Jack").op(Operator.StartWith).ic()
        .field(User::getRoleId, 1)
        .orderBy(User::getId, "asc")
        .page(2, 10)
        .build()
List<User> users = beanSearcher.searchList(User.class, params);

这里使用的是 BeanSearcher 检索器，以及它的 searchList(Class<T> beanClass, Map<String, Object> params) 方法。

运算符约束

上文我们看到，Bean Searcher 对实体类中的每一个字段，都直接支持了很多的检索方式。

但某同学：哎呀！检索方式太多了，我根本不需要这么多，我的数据量几十亿，用户名字段的前模糊查询方式利用不到索引，万一把我的数据库查崩了怎么办呀？

好办，Bean Searcher 支持运算符的约束，实体类的用户名 name 字段只需要注解一下即可：

@SearchBean(tables="user u, role r", joinCond="u.role_id = r.id", autoMapTo="u") 
public class User {

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

    // 为减少篇幅，省略其它字段...
}

如上，通过 @DbField 注解的 onlyOn 属性，指定这个用户名 name 只能适用与 精确匹配 和 后模糊查询，其它检索方式它将直接忽略。

上面的代码是限制了 name 只能有两种检索方式，如果再严格一点，只允许 精确匹配，那其实有两种写法。

（1）还是使用运算符约束：
@SearchBean(tables="user u, role r", joinCond="u.role_id = r.id", autoMapTo="u") 
public class User {

    @DbField(onlyOn = Equal.class)
    private String name;

    // 为减少篇幅，省略其它字段...
}
（2）在 Controller 的接口方法里把运算符参数覆盖：
@GetMapping("/index")
public SearchResult<Map<String, Object>> index(HttpServletRequest request) {
    Map<String, Object> params = MapUtils.flatBuilder(request.getParameterMap())
        .field(User::getName).op(Operator.Equal)   // 把 name 字段的运算符直接覆盖为 Equal
        .build()
    return mapSearcher.search(User.class, params);
}

条件约束

该同学又：哎呀！我的数据量还是很大，age 字段没有索引，我不想让它参与 where 条件，不然很可能就出现慢 SQL 啊！

不急，Bean Searcher 还支持条件的约束，让这个字段直接不能作为条件：

@SearchBean(tables="user u, role r", joinCond="u.role_id = r.id", autoMapTo="u") 
public class User {

    @DbField(conditional = false)
    private int age;

    // 为减少篇幅，省略其它字段...
}

如上，通过 @DbField 注解的 conditional 属性， 就直接不允许 age 字段参与条件了，无论前端怎么传参，Bean Searcher 都不搭理。

参数过滤器

该同学仍：哎呀！哎呀 ...

别怕！ Bean Searcher 还支持配置全局参数过滤器，可自定义任何参数过滤规则，在 Spring Boot 项目中，只需要配置一个 Bean：

@Bean
public ParamFilter myParamFilter() {
    return new ParamFilter() {
        @Override
        public <T> Map<String, Object> doFilter(BeanMeta<T> beanMeta, Map<String, Object> paraMap) {
            // beanMeta 是正在检索的实体类的元信息, paraMap 是当前的检索参数
            // TODO: 这里可以写一些自定义的参数过滤规则
            return paraMap;      // 返回过滤后的检索参数
        }
    };
}

某同学问

参数咋这么怪，这么多呢，和前端有仇么

  1. 参数名是否奇怪，这其实看个人喜好，如果你不喜欢中划线 -，不喜欢 op、ic 后缀，完全可以自定义，参考这篇文档：

https://searcher.ejlchina.com/guide/latest/params.html#%E5%AD%97%E6%AE%B5%E5%8F%82%E6%95%B0

  1. 参数个数的多少，其实是和需求的复杂程度相关的。如果需求很简单，那么很多参数没必要让前端传，后端直接塞进去就好。比如：name 只要求后模糊匹配，age 只要求区间匹配，则可以：
@GetMapping("/index")
public SearchResult<Map<String, Object>> index(HttpServletRequest request) {
    Map<String, Object> params = MapUtils.flatBuilder(request.getParameterMap())
        .field(User::getName).op(Operator.StartWith)
        .field(User::getAge).op(Operator.Between)
        .build()
    return mapSearcher.search(User.class, params);
}

这样前端就不用传 name-op 与 age-op 这两个参数了。

其实还有一种更简单的方法，那就是 运算符约束（当约束存在时，运算符默认就是 onlyOn 属性中指定的第一个值，前端可以省略不传）：

@SearchBean(tables="user u, role r", joinCond="u.role_id = r.id", autoMapTo="u") 
public class User {

    @DbField(onlyOn = Operator.StartWith)
    private String name;
    @DbField(onlyOn = Operator.Between)
    private String age;

    // 为减少篇幅，省略其它字段...
}
  1. 对于 op=bt/il 的多值参数传递，参数确实可以简化，例如：

简化方法：只需配置一个 ParamFilter（参数过滤器）即可，具体代码可以参考这里：

https://github.com/ejlchina/bean-searcher/issues/10

入参是 request，我 swagger 文档不好渲染了呀

其实，Bean Searcher 的检索器只是需要一个 Map<String, Object> 类型的参数，至于这个参数是怎么来的，和 Bean Searcher 并没有直接关系。前文之所以从 request 里取，只是因为这样代码看起来简洁，如果你喜欢声明参数，完全可以把代码写成这样：

@GetMapping("/index")
public SearchResult<Map<String, Object>> index(Integer page, Integer size, 
            String sort, String order, String name, Integer roleId,
            @RequestParam(value = "name-op", required = false) String name_op,
            @RequestParam(value = "name-ic", required = false) Boolean name_ic,
            @RequestParam(value = "age-0", required = false) Integer age_0,
            @RequestParam(value = "age-1", required = false) Integer age_1,
            @RequestParam(value = "age-op", required = false) String age_op) {
    Map<String, Object> params = MapUtils.builder()
        .field(Employee::getName, name).op(name_op).ic(name_ic)
        .field(Employee::getAge, age_0, age_1).op(age_op)
        .field(Employee::getRoleId, roleId)
        .orderBy(sort, order)
        .page(page, size)
        .build();
    return mapSearcher.search(User.class, params);
}

字段参数之间的关系都是 “且” 呀，那 “或” 呢？ “且” “或” 任意组合呢？

上文所述的字段参数之间确是都是 "且" 的关系，至于 “或”，虽然这种使用场景不太多，但 Bean Searcher 仍然支持哦（而且很 方便 且 功能强大），详细可以参考这里：

https://searcher.ejlchina.com/guide/latest/params.html#%E9%80%BB%E8%BE%91%E5%88%86%E7%BB%84%EF%BC%88since-v3-5%EF%BC%89

这里就不再复述了。

上文中的 sort 与 onlySelect 等参数，它们的值时数据表的字段名吗，存在 SQL 注入的风险吗？

这点您完全安心啦，SQL 注入这么低级的错误在框架设计之处早已规避。参数 sort 与 onlySelect 等它们的值全都是 实体类 的 属性名（而非数据表的字段），当用户传的值不是某个属性名时，框架会自动忽略它们，绝不存在注入问题滴。

不仅如此，Bean Searcher 为了保证您的服务安全，还自带 分页保护 功能，可以有效阻击客户端的恶意大页请求。

开发效率真的提高 100 倍了吗？

从本例其实可以看出，效率提升的程度依赖于检索需求的复杂度。需求越复杂，则效率提高倍数越多，反之则越少，如果需求超级复杂，则提高 1000 倍都有可能。

但即使我们日常开发中没有如此复杂的需求，开发效率只提升了 5 到 10 倍，那是不是也非常可观呢？

结语

本文介绍了 Bean Searcher 在复杂列表检索领域的超强能力。它之所以可以极大提高这类需求的研发效率，根本上归功于它 独创 的 动态字段运算符 与 多表映射机制，这是传统 ORM 框架所没有的。但由于篇幅所限，它的特性本文不能尽述，比如它还：

要了解更多，先来点个 Star 吧 : Github 、Gitee。

Bean Searcher 是我在工作中总结封装出来的一个小工具，公司内部已使用了 5 年，经历大小项目三四十个，且 持续在更新维护，只是最近才着手完善文档分享给大家，如果你喜欢，一定去点个 Star 哦 _。

再奉上 Bean Searcher 的详细文档：https://searcher.ejlchina.com/

最后，再来个 Demo 地址：

如果觉得不错，别忘 Star 哦：Github 、Gitee。

下篇：最近火起的 Bean Searcher 与 MyBatis Plus 倒底有啥区别？

代码，也喜欢纯手工的，因为这样才能造出真正的艺术品。

上一篇下一篇

猜你喜欢

热点阅读