SpringDataJPA与MyBatis简单对比
Spring Data JPA 与 MyBatis对比
做一个自己的项目，在考虑这方面的问题，以往都是使用的mybatis或者之前有将hibernate封装成了类似MyBatis的逻辑。以前只知道Mybatis很“百搭”，几乎啥项目都可以用，不管多大，多小。而且还有MyBatis Plus等插件。
mybatis-generator : 根据数据库表自动生成entity和dao层代码的插件
mybatis-plugin: 快速切换dao层方法与mapper.xml的配置映射
mybatis-pagehelper: 分页插件
既然这么好用，为啥还有hibernate（或者Spring Data JPA）存在呢？这么简单还需要啥考虑。然而当你网上去看这些比对，很多人基于表象去说，脱离项目或者不思考本质原因去探讨。难道因为狗好使就要狗去拿耗子吗？（虽然狗拿耗子也没啥问题哈哈哈哈）
之后看到一下这篇文章，豁然开朗。（虽然还是不知道该用啥，比较没有统筹思考，还处于爱用啥用啥，抛硬币吧）
Spring Data JPA是Spring Data的子模块。使用Spring Data，使得基于“repositories”概念的JPA实现更简单和容易。Spring Data JPA的目标是大大简化数据访问层代码的编码。作为使用者，我们只需要编写自己的repository接口，接口中包含一些个性化的查询方法，Spring Data JPA将自动实现查询方法。
JPA默认使用hibernate作为ORM实现，所以，一般使用Spring Data JPA即会使用hibernate。我们再看看hibernate的官方概念，Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，它将POJO与数据库表建立映射关系，是一个全自动的orm框架，hibernate可以自动生成SQL语句，自动执行，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。
MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJOs(Plain Old Java Objects,普通的 Java对象)映射成数据库中的记录。
这样看，Spring Data JPA与MyBatis对比，起始也就是hibernate与MyBatis对比。所以，我们直接来比较后两者。
从基本概念和框架目标上看，两个框架差别还是很大的。hibernate是一个自动化更强、更高级的框架，毕竟在java代码层面上，省去了绝大部分sql编写，取而代之的是用面向对象的方式操作关系型数据库的数据。而MyBatis则是一个能够灵活编写sql语句，并将sql的入参和查询结果映射成POJOs的一个持久层框架。所以，从表面上看，hibernate能方便、自动化更强，而MyBatis 在Sql语句编写方面则更灵活自由。
但这只是从使用层面上看两者的区别，并未涉及的本质。但如果看问题，值看浅层次、表象问题的话，就不能理解技术本质，也不能发挥技术的最多效用。所以，如果更上一个抽象层次去看，对于数据的操作，hibernate是面向对象的，而MyBatis是面向关系的。当然，用hibernate也可以写出面向关系代码和系统，但却得不到面向关系的各种好处，最大的便是编写sql的灵活性，同时也失去面向对象意义和好处——一句话，不伦不类。那么，面向对象和关系型模型有什么不同，体现在哪里呢？实际上两者要面对的领域和要解决的问题是根本不同的：面向对象致力于解决计算机逻辑问题，而关系模型致力于解决数据的高效存取问题。我们不妨对比一下面向对象的概念原则和关系型数据库的不同之处：
面向对象考虑的是对象的整个生命周期包括在对象的创建、持久化、状态的改变和行为等，对象的持久化只是对象的一种状态，而面向关系型数据库的概念则更关注数据的高效存储和读取；
面向对象更强调对象状态的封装性，对象封装自己的状态（或数据）不允许外部对象随意修改，只暴露一些合法的行为方法供外部对象调用；而关系型数据库则是开放的，可以供用户随意读取和修改关系，并可以和其他表任意的关联（只要sql正确允许的情况下）；
面向对象试图为动态的世界建模，他要描述的是世界的过程和规律，进而适应发展和变化，面向对象总是在变化中处理各种各样的变化。而关系型模型为静态世界建模，它通过数据快照记录了世界在某一时候的状态，它是静态的。
从上面两者基本概念和思想的对比来看，可以得出结论hibernate和MyBatis两个框架的侧重点完全不同。所以我们就两个框架选择上，就需要根据不同的项目需求选择不同的框架。在框架的使用中，也要考虑考虑框架的优势和劣势，扬长避短，发挥出框架的最大效用，才能真正的提高项目研发效率、完成项目的目标。但相反，如果使用Spring Data JPA和hibernate等ORM的框架而没有以面向对象思想和方法去分析和设计系统，而是抱怨框架不能灵活操作sql查询数据，那就是想让狗去帮你拿耗子了。
那么，话题再说回来，使用两个框架时候的时候，也要注意最佳的步骤和流程。下面我们来分别讨论一下，hibernate的一般使用步骤如下：
分析、抽象和归纳出系统中的业务概念，并梳理出各个业务概念之间的关系——创建概念模型
根据概念模型，进一步细化设计系统中的对象类以及类的依赖关系——创建设计模型
将设计好的类映射到数据库的表和字段配置好
hibernate可以根据配置信息自动生成数据库表，这个时候也可以集中精力去梳理一下表关系，看看表结构是否合理，并适当调整一下类和表的映射关系，重新生成表结构
完成以上步骤，基本上完成了体统中主要的业务概念类和表结构的设计工作，只是完成表结构设计的出发点事如何持久化系统的对象，同时兼顾数据库表、字段、字段类型、表的关联关系的合理性和合规性，而不是单纯表设计。这两者思考和关注点还是有很大差别的。另外，需要说明一点，这只是使用hibernate的最通用步骤，实际操作过程中还是需要根据具体项目情况来安排。
而MyBatis对于面向对象的概念强调比较少，更适用于灵活的对数据进行增、删、改、查，所以在系统分析和设计过程中，要最大的发挥MyBatis的效用的话，一般使用步骤则与hibernate有所区别：
综合整个系统分析出系统需要存储的数据项目，并画出E-R关系图，设计表结构
根据上一步设计的表结构，创建数据库、表
编写MyBatis的SQL 映射文件、Pojos以及数据库操作对应的接口方法
这样看来MyBatis更适合于面向关系（或面向数据、或面向过程）的系统设计方法，这样的系统一般称为“事务脚步”系统（事务脚步（Transaction Script） 出自Martin Fowler 2004年所著的企业应用架构模式（Patterns of Enterprise Application Architecture））。而hibernate（也可以说Spring Data JPA)更适合于构建领域模型类的系统。当然，我们也不能说MyBatis无法构建领域模型驱动的系统，而hibernate无法构建事务脚步系统。只是用MyBatis构建领域模型要做更多、跟脏、更累的工作；而用hibernate构建一个事务脚本系统有些大材小用，数据的查询反而没那么灵活。
综合上面所有描述和对比，我们对这两个框架的本质区别应该有所了解了。我们了解了这些区别，可以帮助我们选择更合适的框架，同时，也可以利用不同的框架，让他们去做更合适事，这也是所谓的物尽其用吧，更不至于我们“为物所役”。
以上是 SpringDataJPA与MyBatis简单对比 的全部内容， 来源链接： utcz.com/z/515767.html
