spring data jpa与mybatis的选型比较

先去使用任意一种，然后当你发现现在框架有什么痛点的时候，你希望进一步优化的时候，再看看其他框架是否解决了你的痛点。 你就会明白另一个框架的优势了

有一天你在吃葡萄，你发现吐籽太麻烦了。在想，不用吐籽就好了。
然后呢，你发现了，无核白葡萄，没有籽。
葡萄好吃，但是不容易保存。你想着更容易保存就好了。
然后呢，你发现了葡萄干。
你是公司的零食负责人。发现在办公室放的无核白葡萄消耗太快，经费不足。于是乎你把公司的零食换回了有核的葡萄。

吃葡萄，是需求。提供什么葡萄，是技术。

现在有很多开发人员学习其实有个怪圈，就是执着于一个技术的表面以及技术本身。经常为了学某个技术而去学，不考虑它好在哪里。比如说spring security ，安全框架，都知道它实现了授权，鉴权等操作。但是，就单纯请求拦截来看，我用aop来拦截所有请求，来控制权限不可以吗？当你发现当前技术有什么限制你的时候，你就会明白其他框架的意义了。

扯远了说回来，现在一个场景，你手头有个项目

1. 原始JDBC对接数据库。发现自己组装对象太痛苦，而且还需要自己建表。累死个人。有个框架能自动组装对象，还能自动建表就好了。
2. SpringDataJpa框架。然后你发现了Springdatajpa，你仿佛打开了新世界的大门，原来的简单的增删改查都不用写了，直接继承到。而且数据库表也不用建了，直接自动生成。原来一天的数据库操作的代码，现在完全不用写，简单的条件查询，一条语句就搞定。爽到飞起。但是随着项目体量的增大，用户数量激增。表结构慢慢复杂起来，对查询性能也有了要求。然后你在想，有没有能便于优化数据库语句性能的解决方案啊。jpa优化性能并不是那么便利。
3. mybatis：然后你发现了mybatis，你发现你打开了又一扇大门。直接映射返回对象，前台所需要的数据库建个DTO类就行，多表关联的数据也可以一个DTO接收所有数据。根据条件组装各种SQL，简直是爽爆了。
4. 换回jpa：你改给人做项目了，甲方爸爸经常换，公司经常强制要求数据库从mysql换成oracle，但是业务比以前简单了。你发现mybatis因为sql纯手写，依赖于数据库。不便于换数据源。你想起了不依赖数据源的jpa，你把原有项目简化了一下后，换回了jpa，你发现现在可以服务于多个甲方爸爸的数据源，并且不需要改查询，换个配置全搞定。
5. 领悟：回想自己在多个框架跌爬滚打，明白了技术是服务于业务的，没有绝对“银弹”的技术，只有适合当前业务的技术。

上面故事讲的有点长了，来说下自己的理解。

其实现在市面上对比这里啊框架，我觉得他们大多都是在描述技术上的区别。我的看法是

• jpq是面向对象的思想，一个对象就是一个表，强化的是你对这个表的控制。jpa继承的那么多表约束注解也证明了jpa对这个数据库对象控制很注重。
• mybatis则是面向sql，你的结果完全来源于sql，而对象这个东西只是用来接收sql带来的结果集。你的一切操作都是围绕sql，包括动态根据条件决定sql语句等。mybatis并不那么注重对象的概念。只要能接收到数据就好。

面向sql就更利于优化，因为sql可以优化的点太多了。面向对象就更利于移植，因为数据对象不依赖于数据源。俩系统的用户分页语句可能不一样，但是属性都是那么几个。

以上，手机编排，不够细致。有时间再去电脑上重新排版吧……（如果有这个需求的话）