关于 MyBatis-Flex 抄袭 MyBatis-Plus 的澄清
大家好,我是 MyBatis-Flex 的作者,抱歉占用大家时间了。
最近有关于 MyBatis-Flex 抄袭 MyBatis-Plus 的许多言论,同时附带了一些所谓的 “证据”,这个可能引起许多误会。
比如:《比互联网寒冬更冷的,是开源人的心》,还有其他一些额外的朋友圈等。
因此,作为 MyBatis-Flex 的作者,我觉得有必要澄清一下。
首先从为什么要写 MyBatis-Flex 说起。
MyBatis-Plus 是一个优秀的 ORM 开源框架,但是在 10 多年的工作中,我一直是 JFinal 框架的忠实粉丝,JFinal 包含了 MVC 和 ORM,因此,一直以来工作中都在使用 JFinal,很少使用其他 ORM。为此,还基于 JFinal 开发了一个开发框架,叫 JBoot,JBoot 也在 2019 年获得了 Gitee 的评选为 GVP 项目(Gitee 最有价值的开源项目)。
一次偶然的事情,我们的甲方要求我们必须使用 Spring + MyBatis 技术栈,因此我们开始做调研,开始做 ORM 选型,其中包括了 tkMapper、Fluent-MyBatis 以及 MyBatis-Plus。
经过一段时间的调研后,我们发现 MyBatis-Plus 的 star 数是以上几个开源项目里最多的。本来我们是计划使用 MyBatis-Plus,但在深度阅读源码后,发现其架构可能会对性能产生影响,同时也发现了一些我们不太认同的源码注释,这和我们的开源观点产生分歧,因此,产生了自己来编写一个新的框架的想法。
比如这些注释,MyBaits-Plus 官方源码在:https://gitee.com/baomidou/mybatis-plus/blob/3.0/mybatis-plus-extension/src/main/java/com/baomidou/mybatisplus/extension/injector/methods/InsertBatchSomeColumn.java
这些注释,我个人表示无法认同。
另外,在 MyBatis-Plus 的技术架构上,其对 MyBatis 增强的方式是:通过 MyBatis 的拦截器来修改用户传递的 SQL,已达到功能扩展和增强的目的。
这样增强的方式,有很多好处,无论是用户通过 MyBatis 的 Mapper 的方法调用,还是通过 XML 编写 SQL 调用。MyBatis-Plus 都能拦截,进而对 MyBatis 进行增强。
但是这样也有一些缺点:那就是每个增强的 SQL 需要经过 JSqlParser (网址:http://github.com/JSQLParser/JSqlParser ) 解析,这会带来许多额外的性能损耗。同时,在数据库日新月异的今天,每个数据库可能都会支持自己独有的特性,我们很担心通过 JSqlParser 去解析 SQL,会带来许多问题,比如可能会有一些独特的 SQL 无法解析。
于是我们在思考,是否有可以脱离 Sql Parser 方式对 MyBatis 进行增强, 在 MyBatis 的官方网站中,我们看到其已经提供了 @Select()
、SqlProvider
等方式,方便我们在 java 源码里执行编写 SQL。
通过一番调研后,我们发现 MyBatis 官方的 mybatis-dynamic-sql (网址:https://github.com/mybatis/mybatis-dynamic-sql) 以及开源框架 Fluent-Mybatis
也是使用了类似的方式:基于 SqlProvider, 而不是基于:拦截器 + JSqlParser。
因此,我们也决定参考 mybatis-dynamic-sql 和 fluent-mybatis 的方式,使用: Mapper + SqlProvider 对 MyBatis 进行增强的设计模式。这种设计模式和 MyBaits-Plus 的设计模式差别是巨大的。
但是,这种设计模式虽然提高了性能,但是也有缺点,那就是无法对在 XML 里编写的 SQL 进行增强,我们团队在内部讨论的时候,突然有一种设想:在 XML 里编写 SQL 的方式,在未来会不会被淘汰?
我们得到的答案是:有这个可能性的!
Spring 1.x~3.x 中,Spring 几乎都是通过 XML + Java 的编写模式,我们编写代码的时候需要在 XML 里定义 bean,然后再在 java 中使用。
不得不说,MyBatis 官方的设计应该(或可能)也 “借鉴” 了 Spring 的 XML + Java 的设计模式。
但是这两年,随着 SpringBoot 的发展,我们很少看到通过 XML + java 来编写协同编写 Spring 项目的场景。MyBatis 官方应该(或可能)也想抛弃掉 XML,才在后来的版本中,陆续推出了@Select()
、SqlProvider
等可以在 Java 项目里直接编写 SQL 的方式。
再后来,MyBatis 应该(或可能)觉得这还不彻底,因此官方直接推出的 mybatis-dynamic-sql, 以彻底解决在 XML 编写 SQL 的问题,到今天为止,mybatis-dynamic-sql 的活跃度和 MyBatis 本身几乎一样高的。
mybatis-dynamic-sql 官方 Git: https://github.com/mybatis/mybatis-dynamic-sql
我们感觉 SpringBoot 以及 MyBatis 的 mybatis-dynamic-sql 都是在为了远离 XML。
因此,通过这一系列的调研结论,我们踏上了开始开发 MyBatis-Flex 之路。
伴随着 Flex 出来一些稳定的版本后,我们开始对 MyBatis-Flex 和 MyBatis-Plus 进行了性能对比,性能的测试结论让我们惊喜:MyBatis-Flex 的许多场景下,至少高出 MyBatis-Plus 5倍或以上,这是测试源码以及结论:https://gitee.com/mybatis-flex/mybatis-benchmark
这样的结论我们团队感到很开心。因此,在 MyBatis-Flex 开源到现在 5 个月时间里,我们孜孜不倦,废寝忘食。在这 5 个月的时间里,连续推出了 50 个版本,这个期间,我几乎没有周末、没有休息。
但是,不知道什么原因,突然看到 MyBatis-Plus 相关开发者发布了 MyBatis-Flex 抄袭 MyBatis-Plus 的言论,我们赶紧自纠自查,是否有哪些在阅读 MyBatis-Plus、Fluent-MyBatis、以及 官方 mybatis-dynamic-sql 等源码过程中,直接 copy 了 MyBatis-Plus 的源码?
同时也有一些人员用于证明 MyBatis-Flex 抄袭 MyBatis-Plus 源码对比的截图:
但是这个图,大家应该能看出,MyBatis-Flex 和 MyBatis-Plus 的源码相识度整体不到 10%。而这对比图里,确实有相识度很高的几个文件,比如:
-
MyBatisSqlSessionFactoryBean
-
MyBatisPlusAtuoConfiguration
-
MyBatisSqlSessionFactoryBuilder
但是 MyBatis-Flex 确实有点冤枉,因为 MyBatis-Flex 的这几个文件,是源于 MyBatis 官方 git(而非 MyBatis-Plus),他们分别是:
-
FlexSqlSessionFactoryBean 网址为:https://github.com/mybatis/spring/blob/master/src/main/java/org/mybatis/spring/SqlSessionFactoryBean.java
-
MybatisFlexAutoConfiguration 网址为:https://github.com/mybatis/spring-boot-starter/blob/master/mybatis-spring-boot-autoconfigure/src/main/java/org/mybatis/spring/boot/autoconfigure/MybatisAutoConfiguration.java
-
FlexSqlSessionFactoryBuilder 复写了 MyBatis 的 SqlSessionFactoryBuilder。
至于其他几个工具类相同,比如 DbTypeUtil 用于解析 DataSource 配置的 url 字符串,然后分析出是哪一种数据库类型,这一点上 MyBatis-Flex 确实参考 MyBatis-Plus 了 com.baomidou.mybatisplus.extension.toolkit.JdbcUtils 以及 Druid 数据源的 com.alibaba.druid.util.JdbcUtils#getDbType 以及 Druid 的 JdbcUtils.getDriverClassName
的部分源码(并不是完全 copy,源码网址:https://github.com/alibaba/druid/blob/master/core/src/main/java/com/alibaba/druid/util/JdbcUtils.java )。
到此,我想,我的澄清的应该都差不多了,希望不要占用大家过多时间,再次抱歉。
开源都不易,最后,希望大家不要恶意评论和发泄情绪。
良言一句三冬暖,恶语伤人六月寒。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
LK-99:第一种室温常压超导体?
过去几天,韩国研究人员在预印本平台 arXiv 发表了两篇论文,声称发现了第一种室温环境压力超导体。 论文摘要(DeepL翻译) 论文1 (https://arxiv.org/abs/2307.12008): 我们在世界上首次成功合成了在常压下工作的室温超导体(Tc 超过 400 K,127 oC),其结构为改性铅磷灰石(LK-99)。临界温度(Tc)、零电阻率、临界电流(Ic)、临界磁场(Hc)和迈斯纳效应证明了 LK-99 的超导性。LK-99 的超导性源于轻微的体积收缩(0.48%)造成的微小结构变形,而非温度和压力等外部因素。收缩是由 Pb(2)-phosphate 绝缘网络中的 Cu2+ 取代 Pb2+(2) 离子引起的,并产生应力。它同时转移到圆柱形柱的 Pb(1) 上,导致圆柱形柱界面变形,从而在界面上形成超导量子阱 (SQW)。热容量结果表明,新模型适用于解释 LK-99 的超导性。LK-99 的独特结构使得微小的扭曲结构在界面中得以保持,这是 LK-99 在室温和环境压力下保持和显示超导性的最重要因素。 论文2 (https://arxiv.org/abs/2307....
- 下一篇
最后的组合:K8s 1.24 基于 Hekiti 实现 GlusterFS 动态存储管理实践
前言 知识点 定级:入门级 GlusterFS 和 Heketi 简介 GlusterFS 安装部署 Heketi 安装部署 Kubernetes 命令行对接 GlusterFS 实战服务器配置(架构 1:1 复刻小规模生产环境,配置略有不同) 主机名 IP CPU 内存 系统盘 数据盘 用途 ks-master-0 192.168.9.91 2 4 50 100 KubeSphere/k8s-master ks-master-1 192.168.9.92 2 4 50 100 KubeSphere/k8s-master ks-master-2 192.168.9.93 2 4 50 100 KubeSphere/k8s-master ks-worker-0 192.168.9.95 2 4 50 100 k8s-worker/CI ks-worker-1 192.168.9.96 2 4 50 100 k8s-worker ks-worker-2 192.168.9.97 2 4 50 100 k8s-worker storage-0 192.168.9.81 2 4 50 100+...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19