为什么老外不愿意用MyBatis？
共 1963字，需浏览 4分钟
·
2020-10-25 05:55
点击“开发者技术前线”，选择“星标?”
让一部分开发者看到未来
来源：知乎@陈龙
原文链接:http://suo.im/5f4ee4
Spring 团队的Josh Long自己在Twitter上做了一个调查。1625次投票，样本量不算大，但也能说明问题。和我答案最后的那些调查图表基本一致。
我们看一下Google Trends的数据：
搜索条件是这样的：
World Wide:
United States:
France:
India:
Canada:
China:
Japan:
其他英文技术网站上的多个统计：
再看看Stack Overflow上的问题数:
(含有hibernate的标签和问题数)
(含有mybatis的标签和问题数)
从以上的结果来看，在国外，准确地说，在中日韩之外的大部分地区，JPA/Hibernate完胜MyBatis，但在国内却完全相反，But Why？
老外为什么不用MyBatis？
为什么会这样呢？我也不知道。一些朋友发表了自己的想法：
回复基本上分两种：
青年程序员都在质疑这个图的可信度
中老年程序员都在感叹国外其实更注重开发效率和面向对象的分析和设计
有个朋友说的非常好：
窃以为，唯独神州大量使用Mybatis，主要看重它不强化业务建模地搞表。造成的后果是，宁可自己写SQL也不意义花力气使用OOAD思维方式梳理业务并建模。而hibernate是OOAD建模后的自然延伸
好吧，下面是我个人的观点：
确实，和对OOAD的重视有关，我在做DDD战术落地的时候，用MyBatis非常蹩脚，用JPA/Hibernate会好很多。
JPA/Hibernate比较复杂，团队中要有人Hold住它，否则及其容易踩坑；另外，真要使用，建议使用它的一个功能子集，不要所有功能都用。也可以尝试使用更简单EBean ORM。
JPA/Hibernate对分库分表的支持有一下坑。虽然，使用Shareding-JDBC或MyCat等技术，可以不关心分库分表，但是，JPA/Hibernate在某些情况下（比如加载子集合的时候）可能会不带分区键。国外分库分表的少，国内几乎是标配。
国内做互联网的Java程序很多都是拷贝阿里的，阿里一开始用例iBatis（日本韩国是怎么回事呢）。大量的老系统都是基于iBatis/MyBatis的，市场上对MyBatis熟悉的人才更多，招聘和培训更容易，有的青年程序员以为“MyBatis早已统一全球了”就是一个很好的证明。
个人的观点：
其实十年前我们主要使用的ORM框架就是iBatis，而阿里巴巴是对国内Java开发者影响最大的一家公司。阿里在国内Java社区的影响力有目共睹，这个大家应该都能感受到, 阿里对Java社区贡献了很多实用的开源工具，并且国内Java开发者对于阿里开源的产品接纳程度也最高。
而且早期阿里系离职工程师的影响力也不可小觑，这些从阿里离职的工程师进入了各个规模的公司, 通常也有担任较高的职位, 拥有着相对较多的话语权, 在新公司继续使用自己熟悉的iBatis就是再正常不过的了。
MyBatis封装较少，提供的切入点较多，适合进行架构。遇到超级复杂的场景的时候有不错的sql支持。曾经JPA适合做增删改，mybatis只擅长查询，但是现在的tk.mybatis已经补上了这一块短板，而JPA的依然没有补上他的查询短板。在复杂情况下需要在代码里嵌入大量sql片段或手动用代码拼装sql，但是老实说，都到这份上了，写sql不是还更快一点？因此，做企业级应用时，如果组内Hibernate会的人多，可以考虑用这个，但是依然会埋下一个性能的坑。做互联网级应用时，建议还是用Mybatis吧。
综合考虑，Mybatis的优点是简单高效，优化起来也方便，比较符合现在的开发节奏，现在的互联网公司都是先快速开发占领市场，然后再优化代码。而且这个过程需求经常是变来变去的，开发人员也有流动性，这种情况下用Mybatis显然更加适合。
扫码加我微信和大佬们零距离
