分享一个真实的实战经历：
项目刚开始使用原始JDBC方式操作数据库，自己手动建表不说，手动组装对象太痛苦，表字段和对象的关系映射写一堆代码，这时候就会想如果有个框架能自动把表和对象关系自动映射，并且能够封装好使用方法，在初始化时还能自动建表就更好了。
查找方案时发现了SpringDataJpa，仿佛打开了新世界的大门，原来通过写SQL查询再转成对象的增删改查都不用写了，表字段和对象的映射也不需要手工写代码去匹配可，直接使用，而且可以开启初始化时自动创建数据库表。原来需要消耗时间的数据库操作代码现在完全不用写了，简单的条件查询，直接调用封装的方法，快到起飞。但是随着业务数据的不断增多，要查询的条件也越来越复杂，查询时效越来越慢，渐渐对查询性能也有了要求。然后就想，在这样的使用便利上，如果有能便于优化数据库查询性能的解决方案就好了。
再次找解决方案，发现了MyBatis，感觉发现了另一个新世界。虽然，它不能直接把表和对象的关系映射自动封装好，但是它可以直接把操作结果映射成需要的对象，只需要建立对应的数据对象DTO就行，并且多表关联查询、复杂条件查询都可以写SQL解决，最重要的是SQL和逻辑代码分析，维护也很方便，SQL优化交给专业的DBA就行，再次好用到起飞。
突然有一天，公司强制要求数据库从oracle换成MySQL，发现Mybatis因为都是写的纯SQL，原来的SQL语法是oracle的，现在都要改，太依赖数据库了，不便于换数据源。这时想起了不依赖数据源的JPA。
总结一下个人看法：
JPA使用完全面向对象的的设计思想，一个表就是一个对象，所有的操作直接操作对象就行，方便、快捷，也不需要关注底层数据源问题，但是表之间的关系复杂了、查询复杂了，这样的操作不是它的强项。
Mybatis是半面向对象、半面向SQL，SQL与逻辑代码分离，查询结果映射成对象，所有操作上层是对象，下层用SQL，数据查询优化上更加实用，因为是写原生SQL，所以换数据源可能麻烦。
还是业内的那句老话，没有绝对“银弹”，只有适合当前业务发展需要的技术。
