为什么老外不愿意用 MyBatis，而在国内工程师却偏偏热衷？

回复“666”，获取一份技术人专属大礼包

开发者技术前整理

参考来源：知乎@陈龙

原文链接:http://suo.im/5f4ee4

本文不会下关于 Mybatis 和 HIB两个持久层框架哪个更好这样的结论。只是摆事实，讲道理，所以，请各位读者勿喷。

一、国外Mybatis 使用情况

Spring 团队的Josh Long自己在Twitter上做了一个调查。1625次投票，样本量不算大，但也能说明问题。和我答案最后的那些调查图表基本一致。

我们看一下Google Trends的数据：

搜索条件是这样的：

World Wide:

United States:

France:

India:

Canada:

China:

Japan:

其他英文技术网站上的多个统计：

再看看Stack Overflow上的问题数:

(含有hibernate的标签和问题数)

(含有mybatis的标签和问题数)

在最近（2018）的 JVM 生态报告中（snyk.io/blog/jvm-ecosys），Mybatis是使用率是很低的。可以看图：

二、国人喜欢 Mybatis 的原因

总结起来，有如下原因：

1.大厂带节奏 国内做互联网的 Java 程序很多都是拷贝阿里的，阿里一开始用例 iBatis（日本韩国是怎么回事呢）。大量的老系统都是基于 iBatis/MyBatis 的，市场上对 MyBatis 熟悉的人才更多，招聘和培训更容易，有的青年程序员以为“MyBatis 早已统一全球了”就是一个很好的证明。

2.简单，学习成本低 小公司需要大量入门级的程序员，像大神甚至一个都请不起，请问大神们那些牛 b 框架哪个更快让菜鸟们上手，降低公司学习成本。注意这个成本会一直跟随公司，想必大神们创业直接前后端分离了，毕竟钱嘛多的是。

3.对于复杂性需求的灵活性高 国内绝大部分项目都是面向表结构编程的，把 java 对象仅当成数据容器，查询和模型变更都设计在一张表上，所谓业务逻辑就是一堆增删改查的 sql 集合，当然用 mybatis 方便。在逻辑不复杂，或者你判断软件生命周期不会超过一年的时候，直接用表结构编程是最方便快捷的。

国内普遍都是分布式，流量和性能决定了需要经常进行优化，而是用 Mybatis 对复杂需求的优化很方便。

4.政治环境 国内好多项目都是应付领导的某些奇葩需求。需要面向领导编程。一大半时间其实都是在解决领导的需求。国内项目需要大量报表统计（看看帆软卖的这么好就知道了），需要提供给领导作为决策。看到这里，各位领导不要骂我 ，真的不是黑领导的。

5.Hibernate 学习成本高 虽然，实际上 SpringDataJPA 是非常简单的，但是，但是，JPA/Hibernate 后期调试跟踪问题很麻烦，改起来也麻烦。别忘了，牛逼如你的人全公司甚至一个都没。还有什么缓存什么 Criteria 什么 Lazy，虽然这些你学了也不见得能用上，但一个框架，你不学还是不行的。而且，JPA 对于增删改很方便，复杂查询却是软肋，有同学会说，JPA 也能写 SQL 语句啊，我想说的是，既然都用 orm 了，你再写 sql，那不就失去了 oop 的内涵了吗？不优雅好吧。

三、老外不喜欢Mybatis 的原因

1.很多老外对 Mybatis 的认知还停留在 iBatis 阶段 实际上在 Mybatis 的应用场景里面，开发者要的就是自动封装，把 sql 查询结果转化为指定的 java 对象。这个在 iBatis 阶段，需要开发者自己定义大量的 xml 配置，去指定数据库表字段与 Java 实体类之间的关系。并且，对于每一条 sql，都需要在 xml 中写相应的语句，虽然有代码生成器，带开发量还是不小的。

但 Mybatis 发展到今天，已经非常完美地做好了自动封装数据对象这件事，支持的插件也比较丰富。对于常见的增删改查，也不需要自己写一行代码，这已经无限接近于 Hibernate 的能力了。

2.喜欢 OOP、DDD，认为写 SQL 不优雅 用 jpa 的核心是让我们关注对象建模，而不是关心底层数据库映射。只有你在考虑数据和行为在一起的充血模型、贴身职责，聚合根状态变迁，值对象不变性的情况下，你才会发现 jpa 给你提供了很多便利，根本不需要关注底层存储模型。

在复杂的逻辑、超长的软件生命周期。使用 DDD 的设计方法是目前看比较合理的选择，维护的成本比较低。

DDD 全称是（Domain-Driven Design)这是 2004 年就出来的理论，复杂逻辑的应对之道。DDD 大会在欧洲等地办了一届又一届，CQRS、Event Sourcing 等探索层出不穷，这也是为什么国外比较流行 JPA 原因。

不过，国内主要是随着这两年随着微服务火爆也有人谈起来 DDD 了。

但其实 DDD 也不是银弹，需要大拿能把控全局，国内缺的就是这种大拿，搬砖的太多。

3.有些老外在技术选型时，不会考虑除 Spring 这种知名框架外的其他技术 无他，唯手熟尔。国外一个项目，做了几年十几年都是很正常的。我以前接触过一个巴基斯坦的电商项目，做了十几年，也跑的好好的，这就是证据。

使用技术也是有惯性的。

4.数据体量和种类没有达到 个人感觉，也咨询了国际友人。老外的项目，在数据体量和种类上完全达不到国内的水平。所以，他们对于性能上的渴求度没有那么高。追求的是稳定，可维护性好。国内一个双 11，如果用 hibernate，那只能死掉了。

也说明，老外的需求主要是在业务上，技术层面较少考虑。

四、作者个人的观点

其实十年前我们主要使用的ORM框架就是iBatis，而阿里巴巴是对国内Java开发者影响最大的一家公司。阿里在国内Java社区的影响力有目共睹，这个大家应该都能感受到, 阿里对Java社区贡献了很多实用的开源工具，并且国内Java开发者对于阿里开源的产品接纳程度也最高。

而且早期阿里系离职工程师的影响力也不可小觑，这些从阿里离职的工程师进入了各个规模的公司, 通常也有担任较高的职位, 拥有着相对较多的话语权, 在新公司继续使用自己熟悉的iBatis就是再正常不过的了。

MyBatis封装较少，提供的切入点较多，适合进行架构。遇到超级复杂的场景的时候有不错的sql支持。曾经JPA适合做增删改，mybatis只擅长查询，但是现在的tk.mybatis已经补上了这一块短板，而JPA的依然没有补上他的查询短板。在复杂情况下需要在代码里嵌入大量sql片段或手动用代码拼装sql，但是老实说，都到这份上了，写sql不是还更快一点？因此，做企业级应用时，如果组内Hibernate会的人多，可以考虑用这个，但是依然会埋下一个性能的坑。做互联网级应用时，建议还是用Mybatis吧。

综合考虑，Mybatis的优点是简单高效，优化起来也方便，比较符合现在的开发节奏，现在的互联网公司都是先快速开发占领市场，然后再优化代码。而且这个过程需求经常是变来变去的，开发人员也有流动性，这种情况下用Mybatis显然更加适合。