更便捷的Mybatis插件——EasyMybatis

本文链接：https://blog.csdn.net/q1472750149/article/details/122364322

更便捷的Mybatis插件——EasyMybatis

easy-mybatis是一个对Mybatis的增强框架（插件）。在Spring集成Mybatis的基础上，将项目开发中对数据库的常用操作统一化。使用本框架可以很便捷的对数据库进行操作，提高开发效率，减少机械行为。

项目主页：mybatis.zuoyu.top

API文档地址：mybatis.zuoyu.top/doc/index.h…

Maven依赖引入


<!-- https://mvnrepository.com/artifact/top.zuoyu.mybatis/easy-mybatis-spring-boot-starter -->
<dependency>
    <groupId>top.zuoyu.mybatis</groupId>
    <artifactId>easy-mybatis-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

复制代码

Gradle依赖引入


// https://mvnrepository.com/artifact/top.zuoyu.mybatis/easy-mybatis-spring-boot-starter
implementation 'top.zuoyu.mybatis:easy-mybatis-spring-boot-starter:1.0.0'

复制代码

框架初衷

这个框架的初衷是，减少Java程序员千篇一律的数据库操作。

对于开发人员来说：

精力应该花费在业务逻辑上，而非机械式的“技术”上。
项目中减少无关痛痒的代码，从抽象的角度看实现。
各司其职，各劳其力，追求项目角度的服务流水线。

服务分离的时代

如今已很难看到单体架构的项目（感兴趣的可以查看我对架构演变的描述《浅谈微服务》），目前的项目大都是通过RESTful、MQ、Socket的方式（协议）进行数据传输。

这让我开始质疑传统JavaWeb项目中的数据库操作模式——即Model(DTO)存在的意义。理论上，数据库设计是不可能完全遵循视图模型的，这就导致“正确”的做法是在项目中引入VO，由多个DTO来组装。

那么，为什么不能用灵活的Map来替代呢？

对一个Map的方法进行拓展，增加其对Json的解析能力，那么是不是就可以摆脱POJO的各种麻烦组装。

思考框架设计

我在思考如何设计这个框架的时候，被需要考虑的方方面面给阻挡住了。

因为一个数据库框架需要考虑的东西实在太多了，比如：

事务机制
类型转换
会话管理

···

思来想去，发现自己方向跑偏了，我只是希望统一数据库操作的接口 + 摆脱Model，没必要重新平地起墙，完全可以在一个现有的框架基础上进行封装。

那么，对这个现有框架的选择就尤为重要了。

现有框架的选择

目前Java中主流的数据库操作框架：

Spring JDBC
Spring Data JPA
Mybatis
Hibernate

选择现有框架有一个原则——“统一数据库操作的接口 + 摆脱Model”是对该框架的加强，而非变异；不能因为“统一数据库操作的接口 + 摆脱Model”而无法使用原框架的部分功能。

“摆脱Model”这个特点，首先就要排除重度ORM框架，也就是支持JPA操作的数据库——Spring Data JPA、Hibernate；原因很简单，这两个框架的强大之处恰恰就在它完全面向Model操作。

剩下的就只有两个框架了，Spring JDBC和Mybatis。其中，Spring JDBC留给了开发人员大量的可操作空间，更加自由，但恰恰是这种自由使得它更加繁琐。而Mybatis是一个轻量ORM框架，准确来说Mybatis不能称为ORM框架，因为它并不是面向Model操作数据库，仅仅是将数据库字段与Model字段互相赋值，并没有做到ORM定义的关系映射。