MyBatis 史诗级裹脚布可以烧了

作为一名 Java 开发者，你一定经历过被 MyBatis XML 支配的恐惧。

当你打开一个 UserMapper.xml，迎面而来的是几百行甚至上千行的 , , , 标签。原本清爽的 SQL 语句被这些 XML 标签切割得支离破碎，仿佛老太太的裹脚布——又臭又长。

如果你也受够了在 XML 标签里写逻辑，受够了为了一个简单的非空判断就要写三行 XML，那么请继续往下看。dbVisitor 的动态 SQL 规则机制，也许就是你一直在寻找的 "剪刀"。

MyBatis 的 XML 地狱

让我们先回顾一下，一个标准的、带有几个查询条件的 MyBatis SQL 是什么样子的：

这段代码的问题在哪里，已经不用多言！这种 一坨一坨 的开发体验看到就难受至极，更别提还要去维护它。

革命性的解法

dbVisitor 作为一个新一代的数据库访问工具，最核心的设计理念之一就是：让 SQL 回归 SQL。

利用 dbVisitor 独创的 规则机制，上面的 XML 代码可以精简为：

   @{and, create_time >= :createTime}

假设只传入参数 name="Tom"，生成的 SQL 如下：

SELECT * FROM tb_user WHERE name = ?

是不是瞬间清爽了？没有了尖括号的视觉干扰，没有了冗余的 XML 闭合标签，只有纯粹的 SQL 逻辑。

你可能会问：@{and, ...} 到底做了什么？它是简单的字符串拼接吗？

当然不是！dbVisitor 的规则是非常智能的，以 @{and, name = :name} 为例，它内置了以下逻辑：

智能判空

引擎会自动检查 key = :key 表达式中的参数。如果参数 :key 为 null，整个 @{and} 规则块会被自动忽略，不会生成任何 SQL。

（注意：空字符串""被视为有效值，不会忽略）

WHERE 处理

如果内容不为空 @{and} 会识别它是否是 WHERE 子句的开头。如果是开头（例如前面没有1=1），它会自动抹去 AND，直接生成 WHERE name = ?

（这一点类似 MyBatis 的标签，但更加隐形）

这一切都是自动发生的，你只需要声明规则，剩下的交给 dbVisitor。

条件判断本该如此性感

MyBatis 中 90% 的 标签都是为了做两件事：

• 参数不为空时，追加查询条件。

• 开关开启时，追加查询条件。

dbVisitor 将这两类高频场景直接内化为最基础的规则，无需任何复杂的标签嵌套。

智能补全

自动检查条件状态选择是否需要自动补全 WHERE/AND/OR 关键字。

    @{and, name = :name} -- 生成 and name = ?

@{and} 和 @{or} 这是最常用的判空规则，它们会自动检查参数是否为 null。

  @{or,  age > :age}   -- 仅当 age 不为空时生成  or  age > ?

@{ifand} 和 @{ifor} 当你需要用布尔值来控制 SQL 时就会使用他们。

SELECT * FROM tb_user @{ifand, !showAll, is_delete = 0}

对比 MyBatis 的臃肿写法以及像老鼠屎一样无处不在的 1=1

仅仅是一个简单的条件，dbVisitor 让你少写了 3 行代码，减少无用的条件判断，这就是效率。

一行代码的 IN 查询

MyBatis 的 标签简直是反人类设计：collection, item, open, close... 配置项多达七八个，而且为了防止集合为空导致 SQL 语法错误，通常还得在外面套一层，简直令人窒息：

if>

而在 dbVisitor 中，利用 @{ifand} 和 @{in} 两个规则的 嵌套使用，你只需要一行：

  @{ifand, !idList.isEmpty, id IN @{in, :idList}}

对比一下，这代码量节省的可不是一点点，而是 降维打击！

忘掉 ， 忘掉逗号

在写 Update 语句时，处理末尾的逗号是最烦人的。dbVisitor 的 @{set}规则完美解决，引擎会自动处理字段间的逗号：

WHERE id = #{id}

MyBatis 用了一大堆标签来解决这个问题：

WHERE id = #{id}

⚠️ 虽然 @{set} 规则很强大，但规则的判断是依赖已经生成的 SQL 进行推断。

当规则没有匹配时，一些意外情况：

WHERE id = :id

MyBatis 的 - - 结构冗长得令人发指，写起来仿佛在填表。最大的麻烦在于即便是使用 @Select 注解仍然逃脱不了 XML 的魔咒。

                      @Param("content") String content);

dbVisitor 让你用 SQL 的思维写 SQL，更符合编程直觉。同样的场景，dbVisitor 只需要这样：

CASE 规则 IF-ELSE 模式

}

}

规则引擎最强大的地方在于其 可组合性。规则可以像乐高积木一样嵌套使用。这意味着你可以用 @{case} 的结果去驱动 @{and} 或者在 @{else} 里写一组 @{if}

比如一个常见的权限控制场景：

• 如果是管理员 (ADMIN)，查询所有数据；

• 如果是部门经理 (MGR)，查询本部门数据；

• 如果是普通员工，只能查自己的数据。

}

注意看，外层的 @{and} 会自动处理连接词：

• 当 role 是 'ADMIN' 时，@{case} 输出空，整个 @{and} 消失。

• 当 role 是 'MGR' 时，内部输出 dept_id = ?，外层自动加上 AND。

这种自然的嵌套组合，让你能用 SQL 结构直接表达复杂的业务逻辑，而不是在 Java 代码和 XML 之间反复横跳。

这就结束了？

规则的强大之处在于无处不在。你不需要为了使用动态 SQL 而强迫自己切换开发模式。无论你身处哪个层级，dbVisitor 的动态规则都能无缝集成。

1. 在 编程式 API (JdbcTemplate) 中使用

不需要 StringBuilder，不需要拼接字符串。

    "SELECT * FROM users @{and, name = :name}", args);

彻底摆脱 @Script 或者