为什么我又写了一个 ORM 框架（MyBatisGX）

为什么我又写了一个 ORM 框架MyBatisGXORM 的铁三角诅咒写了十年 Java持久层框架一直没找到理想的选择。选 MyBatis灵活归灵活但增删改查、分页、批量操作全得手写 XML。每个表都要写一遍机械重复的工作量很大。选 MyBatis Plus开始用的时候确实爽慢慢就发现不对劲在 Service 层拼LambdaQueryWrapper业务代码里到处都是数据库字段名后来我在 Dao 写 default 方法封装 Wrapper。service 是干净了但 dao 里全是样板代码问题只是挪了个地方简单的 1:1 关联查询也得手写 SQL 或者查两次批量插入/更新又要继承接口又要继承类用起来很麻烦选 JPA写代码的时候确实省心出问题就头疼了。不知道哪里又偷偷执行了一条 SQLSpecification 写动态查询像在用 Java 翻译 SQL 语句。N1 查询、分页数据爆炸这些坑踩过几次就不想再碰了。复杂点的报表查询还是老老实实写原生 SQL。这三个框架分别代表了持久层的三个方向要灵活 → 写得累要省事 → 架构糊要自动 → 黑盒坑MyBatisGX 的做法定义查询不实现查询MyBatisGX 的核心思路查询是稳定的业务能力不是临时拼出来的实现细节。Service 层只写业务流程查询逻辑全部收敛到 Dao 层用方法定义清楚地表达出来。方法名查询java代码解读复制代码// 简单查询 ListUser findByNameLike(String name); // 复杂条件 ListUser findByNameLikeAndAgeBetweenOrStatusEq( String name, Integer minAge, Integer maxAge, Integer status ); // 支持任意分组用括号 Statement(value findByNameLikeAnd(AgeOrSex), language StatementLanguage.METHOD) ListUser findByNameLikeAndAgeOrSex(String name, Integer age, Integer sex);方法名就是查询语义不用 WrapperService 里也不用拼条件。查询实体条件太多的时候方法名会很长这时候用 QueryEntityjava代码解读复制代码QueryEntity public class UserQuery extends User { private String nameLike; // 自动解析成模糊查询 private ListLong idIn; // 自动解析成 IN 查询 private ListLong ageBetween; // 自动解析成 BETWEEN } // Dao 层 ListUser findList(UserQuery query);查询条件作为结构化对象传递类型安全IDE 有提示。Service 层不用关心字段名和查询逻辑。动态查询加个Dynamic注解自动生成动态 SQLjava代码解读复制代码Dynamic ListUser findByNameLikeAndId(String name, Long id);参数为 null 的时候条件自动不加入 SQL。关联查询java代码解读复制代码Entity public class User { OneToOne(mappedBy user, fetch FetchType.EAGER) Fetch(FetchMode.BATCH) // 批量抓取解决 N1 private UserDetail userDetail; ManyToMany(mappedBy userList, fetch FetchType.LAZY) Fetch(FetchMode.JOIN) // JOIN 抓取分页不爆炸 private ListRole roleList; }不用写 ResultMap不用手写 JOIN SQL。支持 4 种抓取策略SIMPLE/BATCH/JOIN/NONE按场景选。批量操作业务开发里批量插入/更新/删除太常见了。导入功能、数据同步、批量审核到处都要用。MyBatisGX 直接内置了批量方法java代码解读复制代码// 继承 SimpleDao 就有不用继承额外的接口或类 int insertBatch(ListUser users); // 批量插入 int updateBatchById(ListUser users); // 批量更新 int deleteBatchById(ListLong ids); // 批量删除框架提供的不够用BatchOperation自己定义java代码解读复制代码BatchOperation int insertBatchCustom(BatchData ListUser users, BatchSize int batchSize);不用为了批量功能改架构直接在 Dao 层调用。是 JPA 的换皮吗不是。MyBatisGX 确实用了 JPA 的注解Entity、OneToMany等但只用来描述结构不参与行为控制。JPA 有的东西MyBatisGX 都没有EntityManager、Session 生命周期持久化上下文Persistence Context隐式 SQL 执行、脏检查、自动 FlushMyBatisGX 的执行模型是 MyBatisSQL 预生成启动时扫描 Dao生成 MappedStatementSQL 可被 mapper.xml 完全接管SQL 最终形态对开发者可见、可干预厌恶 JPA 的黑盒运行时但认可它对象建模的成熟设计MyBatisGX 就是这个定位。XML 兜底框架生成的 SQL 有问题需要写复杂的报表查询直接按 MyBatis 原始方式写 XML框架立即失效。xml代码解读复制代码select idfindByNameLike resultTypeUser SELECT * FROM user WHERE name LIKE #{name} /select只要 mapper.xml 里有同名方法MyBatisGX 就不再自动生成。优先级mapper.xml MyBatisGX 自动生成。这是个渐进式框架简单场景零 XML复杂场景随时接管无缝兼容现有 MyBatis 项目还有几个真香的点无缝升级现有 MyBatis 项目原来的 mapper.xml 完全不用动换个依赖、继承个SimpleDao接口就能开始用。逻辑删除、乐观锁、审计字段加个注解就行java代码解读复制代码LogicDelete private Integer deleted; Version private Integer version; GeneratedValue(InputTimeValueProcessor.class) private LocalDateTime createTime;复合主键、字段加密、投影 DTO都支持不需要复杂配置。总结MyBatisGX 不是要替代谁它回答的是这个问题在意代码边界、架构演进和长期维护成本的时候有没有更好的选择只追求写得快现在的 ORM 够用。但如果已经被重复代码、架构腐烂、SQL 黑盒、Specification 折磨过可能不是缺框架是缺一套正确的抽象。作者落木萧萧825链接https://juejin.cn/post/7628156003448995874来源稀土掘金著作权归作者所有。商业转载请联系作者获得授权非商业转载请注明出处。