其实要承认，一个东西用久了都会有习惯心理。mybatis和jpa，两个持久层框架。从底层到用法都不同。但是实现的功能是一样的。所以说一直以来颇有争议。常年混迹于各大qq技术交流群。见过jpa的死忠粉也见过mybatis的铁杆。作为一个不到两年工作经验的小菜鸟来说，你让我分析源码，讲什么底层实现我是讲不出来的。只能作为一个使用者，来谈谈自己对这两个框架的理解。
首先，都知道jpa的前身是著名的ssh中的h——>Hibernate。我到现在还记得学习Hibernate时对它产生的讲解：一个希望不用写sql语句来操作数据库的懒到愿意为此开发一个框架的创始人，其实也够奇葩到值得记住了。而现在的jpa，我觉得主旨也确实在贯彻这个理念。你要承认，jpa的对于单表的简单查询确实简单方便又实用。但是同时，对于多表关联和复杂查询，起码目前为止，要么把复杂查询拆成多个简单查询，要么宁可直接一个nativeQuery = true来原生查询。如果这两点都没能满足你业务的需求，我不敢下定结论说你的设计有问题，但是如此复杂的业务逻辑，身为小白的我实在无法给你建议了。
然后说到mybatis，原谅我入行时间比较晚。从我开始学习java他就已经出现了。听说过他前身好像是ibatis,但是具体就不太了解了。使用上来讲，在那个boot还没有发布的年代，mybatis也曾经是每个程序员必备的基本技能。刚接触的时候mapper映射在我眼中简直是神奇。也算是用了半年多，多少有一定的了解。在这里基本的使用就不多介绍了，反正我一直所应用的也基本都是crud。没到多高深的地步。只能说对于多表查询确实是比较支持。尤其是在业务逻辑多是多表关联的情况下，mybatis绝对比jpa要更加适合。无论是以后的维护还是业务的变更都方便不少。
可能我这么说大家还是不太理解什么时候用jpa什么时候用mybatis。我举个例子：现在业务上A,B,C,D四个表。如果你每个表都会在业务中用到，都需要有单独的增删改查，虽然有一定的关联关系，但是这种情况用jpa就比较合适。ABCD四个java实体不说，每个实体要对应一个repository。然后再repository层进行crud的编写。但是如果业务上A,B,C,D四个表。这四个是关联关系，你几乎不会单独对A,B,C进行操作，而且展现出来的也是D，那么这个时候jpa的使用就会很麻烦，因为你还是要四个实体四个repository。在一个接口中四个repository挨个调用一次。虽然也能完成业务逻辑，但是复杂又麻烦。还要考虑原子性什么的。所以这个时候用mybatis比较合适了。
其实说到这大概对于什么样的业务应该采用哪个在思维上应该有个简单的区分了。不过很多时候很多项目不是能一下子分辨出来属于哪种的。所以还是需要具体判断的。虽然工作才一年多，但是外包让我经历了多个项目的经验告诉我，千万别相信那些所谓的“某某大佬”随便给你的建议。（我是指那些连具体业务都不知道就给你建议jpa好还是mybatis好的那种。如果真的是大佬而且愿意为你的项目深入分析并且给出答案，那还是值得参照的）因为以前有一次在老板给了我一个小项目让我独立完成的时候我选择了咨询群里的大佬。记得很清楚当时大佬给的意见就是mybatis。还说了mybatis的好多优点。然后我就自然而然的用了。结果嘛，大家能想到我一个人能完成的项目会有多小，业务多简洁。虽然用mybatis也做完了。但是现在想想，要是换成jpa肯定会更加快速方便的开发。我讲这段经历绝对没有别的意思，只是想告诉大家业务怎么样还是自己最清楚。很多时候我们的询问可能不是很全面，所以别人给的建议也不是很合适。
然后还有一些额外的东西。比如说spring家族的态度。我不知道各位有没有跟我一样的大众心理。一个jar包。只要是org.springframework.boot这个分组的，就比较信赖。毕竟有那么庞大的家族做后盾呢~~而且boot真的是封装的越来越具体了~~~反正依稀记得以前spring创建个项目，还要配置这个那个的，偶尔马虎下还报个错。一个结构要搭好一会儿的（也可能是我当时比较菜，但是确实要配置一些东西）而现在呢，spring boot，差不多创建了，依赖导一下就可以跑。真的是相当方便。方便到前一段时间群里一个小孩子问了一个spring 配置的问题，我居然觉得有点想不起了~~哎~~spring boot用多了，都把人用成sb了~~~哈哈，开玩笑的，别当真。反正现在代码的高度封装让我们用什么都更加简单了。而boot对jpa的封装，反正我个人是觉得在单纯的配置上面，除了在配置文件中连接下数据库然后添加个data-jpa的依赖，搞定了就。这也是个人比较喜欢jpa的一点。部署是真的简单。而且官方文档还很全面。也在持续维护更新。我觉得单纯从spring的角度，jpa就值得一试。当然了，这个属于个人心态，但是如果是新手在自己做练手项目的时候，我还是推荐jpa。
对了，再额外安利一下，这个就涉及到了个人的使用经验。以前只有mybatis有代码生成器，所以基于这个原因有一段时间我还比较喜欢用mybatis。但是现在jpa也有了代码生成器。从表到实体和从实体到 表都可以自动生成的。小白们别手敲啦~~~（ps：是因为我以前做过这种事所以在此提醒一下跟我一样白的小盆友，知道的可以掠过）。至于代码生成器的使用，只要你知道了这个概念去百度都能找到用法，在这里我就不多说了。实在不知道的也可以问我，我要是看到了会回的，虽然我觉得找我不如自己百度呢。
然后再说个题外话，其实jpa和mybatis都是很有必要学的。因为遇到的项目会各种各样，所以两者各有长短。还有就是如果自己没话语权的时候，最好上级让用啥就用啥。注意！我说的是最好。如果说你们team氛围比较好，然后领导比较愿意接受意见什么的，你出与实际考虑确实有不同的意见可以提出来。不然的话还是老老实实听指挥吧。别管你以为有多不合理。我不是在宣扬什么消极理念。而且在一个team中领导所考虑的可能和你考虑的点不一样。或者说你知道的不太全面等。没必要非要为了所谓的自己为正确然后最后弄的大家都不愉快。尤其是最后还可能结果也不会想你想的那样。大家都是做技术的，有点自视清高或者说自己的见解很正常。但是切记人还是要谦卑。给大家讲一个实际发生的故事。
我们team一直是手写接口文档，然后人工维护的。确实现在有很多文档生成工具，我自己也用过swagger做过demo，但是团队里有的人不会用，而且其实维护起来也很麻烦（可能是没用习惯的麻烦，这不是主要的），而且我们公司接的项目都比较小。所以领导说就手工维护接口文档吧。然后前一段时间来了个实习的小孩，可能是学习确实很努力，接触的技术很多。然后一开始整天也干劲儿满满的自觉加班在公司学习到很晚那种。后来开了个项目，小孩看到我们手工维护接口可能是觉得比较low，所以跟我们领导建议用swagger。然后我们领导就很委婉的说他回去了解了解，考虑考虑再说，先这么手工维护吧。然后自那以后我们再手动改接口，他就会讲这样怎么怎么，巴拉巴拉的。重点是有一次我们team中工作时间比较久的一个大哥因为接口对接没对接好，所以测试的时候有点小bug，这个孩子又开始抱怨说用手写文档怎么怎么不好。。然后我们领导就爆发了，劈里啪啦一顿训斥，大概意思就是这里的人谁不比他有经验啊，他优越什么啊，之所以不改是因为要前端后端都要熟悉这个框架，没必要。。然后那以后这个小孩沉默多了，也不知道是顿悟了什么还是说生气。后来不久这个小男孩就走了。辞职还是被劝退也都不知道。其实单单从这个故事看，一个swagger的事，说不上谁对谁错的。非要说的话，我们一个外包公司，肯定是需求对付做完就行了，老板不愿意拿时间来让员工学习一些没必要的技能。从小男孩的角度，一个实习生没有决定权却非要坚持主见。这个也算是职场经验了 吧~~~说着说着跑题了~~~
反正核心几句话“：
1，jpa和mybaits各有优缺点。
2，使用哪个合适要结合具体的业务进行分析。
3，当你没有决定权的时候，最好领导让用什么用什么。
对于咱们技术人员来讲，两个都要熟悉，会用。
喏，手打不易，大家动动小手分享转发点赞评论啥的~~~~
