大家好，我是 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），他们分别是：
至于其他几个工具类相同，比如 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 ）。
到此，我想，我的澄清的应该都差不多了，希望不要占用大家过多时间，再次抱歉。
开源都不易，最后，希望大家不要恶意评论和发泄情绪。
良言一句三冬暖，恶语伤人六月寒。
