关于SQL和ORM的争论，永远都不会终止，我也一直在思考这个问题。昨天又跟群里的小伙伴进行了一番讨论，感触还是有一些，于是就有了今天这篇文。

 

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

 

一、事件起因

关于Mybatis和JPA孰优孰劣的问题，争论已经很多年了。一直也没有结论，毕竟每个人的喜好和习惯是大不相同的。我也看过知乎上一些问答，各有各的理由，感觉都挺有道理。如果让我不带感情色彩地去分辨，其实我也是懵的，因为真的是公说公有理婆说婆有理。

 

而在国内，不得不承认，到今年（2019年），用Mybatis的公司确实是要比用JPA的多，但是在2015年以前，用Hibernate的公司确实也是很多的。为什么在国内，会有这样的现象发生？而在国外，老外会一如既往地使用JPA呢？我们来分析分析。

 

二、目前生态

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

 

 

 

可以看出，Mybatis的占比只有可怜的6%，大家看到这个统计结果应该会很吃惊，你会觉得，不对啊，我公司以及我很多朋友都在用Mybatis啊，好像没听说过有人用JPA的，这个统计结果是错的吧？造成这种印象的原因也很简单，因为语言和技术的流行度有地域性偏差的，接着来看下Google Trends就明白了：

 

红色部分是Mybatis的主要使用人群。

 

图违规，删除了。

 

再从下面这个对比来看，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的内涵了吗？不优雅好吧。

 

四、老外喜欢JPA的原因

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，那只能死掉了。

 

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

 

五、一点感悟

整个状况，和对OOAD的重视有很大关系，我在做DDD技术落地的时候，用MyBatis非常蹩脚，用JPA/Hibernate会好很多。

 

JPA/Hibernate比较复杂，团队中要有人Hold住它，否则及其容易踩坑；另外，真要使用，建议使用它的一个功能子集，不要所有功能都用。也可以尝试使用更简单EBean ORM。

 

JPA/Hibernate对分库分表的支持有一下坑。虽然，使用Shareding-JDBC或MyCat等技术，可以不关心分库分表，但是，JPA/Hibernate在某些情况下（比如加载子集合的时候）可能会不带分区键。国外分库分表的少，国内几乎是标配。