前言
在java的orm江湖中,腥风血雨,诞生出过很多门派。
-
野球拳十段高手, 追求返璞归真,JDBC API和Spring JdbcTemplate追求者。
除了野球拳派之外,还有2大江湖传说!
-
屠龙宝刀拥有者Hibernate(JPA): 有自动跟踪功能,一按按钮,自动映射,级联查询,但有时候导航不准,不知道命中了啥目标。HIbernate是一代大哥,Spring Data JPA继续发扬光大其法力。
-
倚天宝剑拥有者ibatis(MyBatis): MyBatis在国内互联网界,呼风唤雨,毒霸天下。在带头大哥Mybatis的号召下,其旗下有一众迷弟: TkMybatis、mybatis-plus、fastmybatis、mybatis-enhance、Ourbatis、mybatis-pro ... ...
倚天和屠龙的纠纷,由来已久,它们究竟谁更牛掰点,江湖上有各种传说:
- 为啥国人偏爱Mybatis,而老外喜欢Hibernate/JPA呢?
- MyBatis还是JPA? 终于有答案了!
- 浅谈mybatis和jpa的区别
总之,各种爱恨情仇。然就国内而言,MyBatis以其号称的半自动化特性,迎合了国内业务模型设计混乱,时不时复杂多表join、各种骚操作的现状,也号称DBA可以帮助REVIEW SQL, 不会陷入到hibernate(JPA)自动导航的谜之操作陷井中;
但也因其半自动化,孜孜不倦的码农们,前仆后继的将其致力于更加自动化,让码农们提高工作效率(内卷)。
在MyBatis的一位新晋迷弟中,fluent mybatis在机缘巧合中,静坐冥思7天7夜,悟出了屠龙和倚天的秘密,将二者合二为一,取出了藏于其中的九阴九阳。
FluentMybatis的功力
根据方法名称自动实现数据操作 + 参数注解校验
- 支持下列关键字
- topNBy: 符合条件的前N条记录, N为对应的数字
- findBy, countBy, existsBy: 查询符合条件的记录、总数、true/false
- listBy, stdPagedBy, tagPagedBy, pagedBy: 列表查询、分页查询
- 支持javax.validation字段约束处理
级联操作,1+N优化
- 生成代码时, 支持设置1:1, 1:N关联关系
- 支持懒加载方式,调用相应的关联接口才真正执行关联sql
- 支持查询列表时,自动消除ORM的1+N的查询问题
- FluentMybatis在发起1+N关联查询时,会自动收集列表的关联外键列表,发起关联表的 IN (外键列表)查询,把1+N查询变为1+1查询。
- 同时,对关联数据自动按照外键在程序内存中进行分组,并把单个关联(列表关联)数据逐个赋值给列表中的元素
-
以上2个步骤都是自动完成,开发者只需了解原理,无需再进行繁复的编码操作,如丝顺滑。
查看测试控制台输出:
- 只执行了2条SQL语句, 符合1+1预期,避免了1+N问题
- 2条SQL各返回2,4条记录,框架进行了数据分组和赋值处理
条件设置,条件WHERE, 江河虽大,只取一瓢
在业务编码的世界中,输入的条件往往是多变的,有很多的组合关系,这时候,如果你固守野球拳式的JDBC(或template)编码,前面将是无尽的炼狱。这时候,java的if else语句,jpa的Criteria,mybatis的Example,或者mybatis xml的
- Spring Boot使用JPA多条件查询mysql
- MyBatis条件判断SQL片段表达式取值和拼接
- mybatis动态SQL
漫漫长夜,无心睡眠,我以为只有我睡不着,原来晶晶姑娘也睡不着!
既然睡不着,我们来探讨探讨技术问题,切磋一下FluentMybtis的解决方案
通过Predicate方式
-
通过直接布尔表达式方式
-
通过大对象断定 + lambada条件表达式
内嵌,子查询
- from (Select 子查询)
- exists (select 1 from ...)
- IN (Select id from ... )
- AND (1 或 2)
- OR (1 且 2)
请问,上述表达式是不是需要需要写mybatis的原生的xml表达式,否则会很复杂???
No,No,No,不需要的,FluentMybatis支持的很好,一发入魂!
执子之魂,与子共生:join的结合和union合并
除了写原生的SQL,ORM框架一般都没提供join和union的编码功能,因为复杂,但fluent mybatis做到了简单。
-
三表关联示例
-
嵌套子查询示例
-
union示例
充血模型,心中有剑手中无剑
弱冠之年成名,手持青钢利剑,曾与河朔群雄争锋。三十岁之前,使用紫薇软剑,威力巨大,曾误伤义士,弃剑于深谷。之后改用重剑,重剑无锋,大巧不工,荡尽天下高手,横行江湖。四十岁之后,花草树木皆可当作兵器,无招胜有招,手中无剑心中有剑,也就是剑气伤人的境界了。
对于简单的,根据Entity值条件进行的操作,忘掉Mapper、Query和Update吧。RichEntity上内置了很多充血的操作,可以自动组装SQL,调用Mapper执行操作。
也可以直接通过Query和Update直接触发Mapper的sql操作,无需再关注Mapper的存在。尽量做到简化编码,简而又简,化有形于无形。
隔山打牛,从rest api直接透杀到数据库
江湖之中,除了武功招式,还有很多门派,立有众多的规矩。分层设计,DDD设计,想进入java的殿堂,岂有不拜码头的道理!!!
但对于后台的增删改查界面,需要做以下事情
- 定义API入参,出参;定义参数约束;
- 定义Controller层,调用Service层
- 定义Service层,调用Dao(Mapper)层
- 调用BeanUtils或者MapStruct,把数据库模型转换为业务模型
姑奶奶好,为什么我总在重复的搬砖啊,为什么Java的框框条条这么多,为什么不能像PHP一样,直接操作数据库搞定一切呢。为什么?为什么?为什么?
别急,FluentMybatis给你一杆到底,只需声明,无需编码(搬砖):和PD讨论完需求,把产品的PRD原型设计一下接口,就可以偷懒喝咖啡的选择。
DEV: 老板,我收工了!
TL: 你只是定义了API规格啊,还有实现呢?
DEV: FluentMybatis已经帮我完成了,只需要引用一下接口实现就ok了
TL, 目瞪口呆ing......
Free Query/Update, 我花开尽百花杀, 野球拳十一级
任你说的天花乱坠,业务的世界你不懂,总有你兜不住的时候。,既然兜不住,360计走为上计。 但我能不能走的优雅点!直接使用Mybatis的xml,当然可以。不过FluentMybatis也提供了一个原生文本sql编码的方式,如果配合JDK17的文本块功能,会不会很爽。
-
customizedByPlaceholder
-
customizedByQuestion
什么,环境支持?租户支持?当然不在话下
环境区隔,租户支持,分页支持,自定义主键支持,这些作为业务系统常用的功能点,当然一个也不能落下。
通过实现接口IDefaultSetter,并在代码生成时设置实现接口就可以了!
甚至,你还可以把FluentMybatis当做一个简单的分表中间件使用!
重要的是,要言而有信,Fluent! Fluent! Fluent Style,行云流水,如丝般的顺滑
- fluent mybatis gitee
- fluent mybatis github
- maven使用
com.github.atool
fluent-mybatis
1.9.3
com.github.atool
fluent-mybatis-processor
1.9.3
provided
-
入门有点点门槛,你需要稍稍了解Java的Annotation Processor工作方式
Fluent Mybatis的很多代码时根据Entity文件通过Annotation Processor编译时生成的,在IDE上需要稍稍有点配置。
idea上需要勾选上下列选项
Rebuild Project后
刷新Maven的工程视图
在eclipse中使用springboot整合fluent-mybatis