数据持久层框架iBatis, Hibernate 与 JPA 比较

      在本文中咱们介绍并比较两种最流行的开源持久框架：iBATIS和Hibernate，咱们还会讨论到Java Persistence API（JPA）。咱们介绍每种解决方案并讨论其所规定的品质，以及在普遍的应用场景中其各自的长处和缺点。而后咱们会基于诸如性能、移植性、复杂性以及对数据模型改变的适应性等因素来比较iBATIS、Hibernate和JPA。

      若是你是一个刚起步的Java程序员，新接触持久性概念的话，那么就把阅读此文看成是接受一次这一主题以及大部分流行的开源持久性解决方案的启蒙。若是你对这三种解决方案都很熟悉，而且只想要一个简单的比较的话，那么你会在“比较持久化技术”一节中找到相应的内容。

理解持久性

持久性（persistence）是数据的一个属性，其确保即便是在应用的生命周期以外数据也是可用的。对于像Java这样的面向对象语言来讲，持久性确保了即便是在建立对象的应用中止执行以后对象的状态还是可访问的。

存在多种实现持久性的方法。传统的解决这一问题的方法是使用文件系统来把须要的信息存储在平面文件（flat file）中。这一方法很难用来管理大量的数据，由于数据分布在不一样的文件中。使用平面文件系统的话维护数据的一致性也是一个问题，由于相同的信息可能会被重复放在各个文件中。在平面文件中查找数据很耗时，特别是若是这些文件还未排序的话。还有，文件系统对并发访问的支持有限，由于它们不能确保数据的完整性。基于上述种种缘由，在寻求持久性时，文件系统并不被视为一个良好的数据存储解决方案。

当前最多见的方法是使用数据库，其充当巨大量数据的存储库。存在许多种类型的数据库：关系型的、层次结构型的、网络型的、面向对象型的等等。这些数据库，以及它们的数据库管理系统（DBMS），不只提供持久性能力，并且管理其所持久的信息。关系数据库是最被普遍使用的类型，关系数据库中的数据被建模成一组相互关联的表。

企业级应用的出现普及了n层架构，其目的是经过把表现、业务和数据库相关代码分离到应用的不一样层级（或是层面）中来提高可维护性。分离了业务逻辑和数据库代码的层面便是持久层，其保持了应用相对于底层的数据库技术的独立性。适当的位置上有了这一强健的层面，开发者就再也不须要操心数据的持久性。持久层封装了存储和检索关系型数据库中的数据的方式。

Java应用传统上使用JDBC（Java Database Connectivity）API来把数据持久到关系数据库中。JDBC API使用SQL语句来完成建立（create）、读取（read）、更新（update）和删除（delete）（CRUD）操做。JDBC代码内嵌在Java类中——换句话说，这类代码与业务逻辑紧密耦合在一块儿。这类代码还在很大程度上依赖于SQL，而SQL并不是是跨数据库的标准；这使得从一种数据库移植到另外一种数据库变得困难起来。

关系数据库技术强调的是数据及其之间的关系，而用于Java中的面向对象范式却并不是关注数据自己，而是关注执行于数据之上的操做。所以，当这两种技术须要携手合做时，就会存在利益冲突。并且，关系数据库并不能知足继承、多态及关联这些面向对象编程概念。当Java应用中的用户定义的数据类型被映射到关系数据库上时，由这一失配致使的另外一个问题就出现了，由于后者并无提供所需的类型支持。

对象关系映射

对象关系映射（object-relational mapping，ORM）已成为了有时被称做对象关系阻抗失配（impedance mismatch）的这一问题的一个解决方案。ORM是一种透明地把应用对象持久到关系数据库中的表的技术。ORM的行为就像是一个虚拟的数据库，对用户隐藏了底层的数据库架构。ORM提供功能来执行完整的CRUD操做并鼓励面向对象的查询。ORM还支持元数据映射以及在应用的事务管理方面提供帮助。

举个例子有助于说明ORM是如何工做的。考虑一个须要持久到数据库中的简单的Car对象，领域模型中的这一Car对象是数据模型中的CAR表的表现形式。Car对象的属性派生自CAR表的各列。在Car类和CAR表之间存在一个直接映射。

存在许多开源的ORM工具，其中包括Hibernate、iBATIS SQL Maps以及Java Ultra-Lite Persistence等。这些工具大多数是提供Java应用和数据库之间的抽象层的持久性框架。持久性框架把应用领域中的对象映射成须要持久在数据库中的数据，这些映射可以使用XML文件或是元数据注解（后者做为Java1.5的组成部分被引入到语言中）来定义。持久性框架的目的是分离数据库相关代码和应用代码（即业务逻辑），从而提升应用的灵活性。持久性框架经过提供一个持久性逻辑的包装器来简化开发过程。

完成了持久性的基本介绍以后，咱们就作好了继续讨论两种最流行的开源持久框架iBATIS和Hibernate的准备。咱们还会介绍Java Persistence API，并讨论这三种解决方案在各类应用场景中的优点和弱点。

什么时候使用iBATIS

iBATIS最好是用在你须要全面地控制SQL的时候，在须要对SQL查询作微调的时候也颇有用。当你在应用和数据库设计两方面都有彻底的控制权的时候，就不该该使用iBATIS，由于在这样的状况下，应用可能会作出修改以适应数据库，或是反过来。在这种情形中，你能够构建一个彻底的对象-关系应用，其余的ORM工具更适于使用，由于iBATIS较为以SQL为中心，其一般被称做反转的——功能齐全的ORM工具生成SQL，而iBATIS直接使用SQL。iBATIS也不适合于非关系型的数据库，由于这类数据库不支持事务和其余iBATIS用到的键特性。

什么时候使用Hibernate

Hibernate最适合用来做为端到端的OR映射的手段。其提供了一个完整的ORM解决方案，但可是不会让你控制查询。对于那些对应用和数据库二者都有彻底的控制权的状况来讲，Hibernate是一种理想的解决方案。在这类状况中，你能够修改应用来适用数据库，反之亦然，在这些状况下你可使用Hibernate来构建一个全对象-关系应用。对于不太熟悉SQL的面向对象编程者来讲，Hibernate是最佳选择。

什么时候使用JPA

JPA应该用在须要标准的基于Java的持久性解决方案的时候。JPA支持继承和多态这两种面向对象编程特性。JPA的缺点是其须要一个实现了其自身的提供程序。这些供应商特有的工具还提供了某些并未定义成JPA规范组成部分的特性，其中一个这样的特性是缓存支持，该功能并未在JPA中作明肯定义，但其中一个最流行的实现了JPA的框架Hibernate对这一功能提供了很好的支持。

此外，JPA被定义成只能在关系数据库上工做。若是你的持久化解决方案须要扩展到其余类型的数据存储上，好比XML数据库上的话，则JPA就不可以用来解决你的持久性问题了。

 

比较持久化技术

如今你已经分析了三种不一样的持久化机制及其运做方式。这些框架中的每一种都有本身的优势和缺点。让咱们来考虑几个参数，这些参数可帮助你肯定其中知足你需求的最佳可行方案。

简易性

在许多应用的开发中，时间是主要的制约因素，特别是当团队成员须要经培训来使用某种特定框架的时候。在这类情形中，iBATIS是最好的选择，该框架是三种框架中最简单的，由于它仅需SQL方面的知识就够了。

完整的ORM解决方案

像Hibernate和JPA一类的传统的ORM解决方案应该用来做为一种彻底的对象-关系映射手段。Hibernate和JPA直接把Java对象映射到数据库表上，而iBATIS则是把Java对象映射到SQL查询的结果上。在某些应用中，领域模型中的对象是根据业务逻辑来设计的，可能不彻底与数据模型匹配，在这种状况下，iBATIS是合适的选择。

对SQL的依赖

老是会存在精通Java的人和更信任SQL的人这样的一种划分，对于一个熟练的Java程序员来讲，他想使用一个无需与SQL有太多交互的持久性框架，那么Hibernate是最好的选择，由于它会在运行时生成高效率的SQL查询。可是，若是你想要使用存储过程来对数据库查询作各方面的控制的话，则iBATIS是推荐的解决方案。JPA还可经过EntityManager的createNativeQuery()方法来支持SQL。

支持的查询语言

iBATIS大力支持SQL，而Hibernate和JPA则是使用它们本身的查询语言（分别是HQL和JPQL），这些语言与SQL相似。

性能

一个应用要成功的话须要具有良好的性能。Hibernate经过提供缓存设施来提升性能，这些缓存设施有助于更快地从数据库中检索数据。iBATIS使用SQL查询，这些查询可经过微调来得到更佳性能。JPA的性能则取决于供应商的实现，根据每一个应用的特有状况作选择。

跨不一样数据库的移植性

有时候，你须要改变应用使用的关系数据库，若是你使用Hibernate来做为持久化解决方案的话，那么这一问题很容易解决，由于Hibernate在配置文件中使用了一个数据库方言属性。从一个数据库移植到另外一个数据库上仅是把dialect属性修改为适当值的事。Hibernate使用这一属性来做为生成特定于某种给定数据库的SQL代码的指南。

如前所述，iBATIS要求你编写本身的SQL代码，所以，iBATIS应用的可移植性取决于这些SQL。若是查询是使用可移植的SQL编写的话，那么iBATIS也是可在不一样的关系数据库之间作移植的。另外一方面，JPA的移植性则取决于其正在使用的供应商实现。JPA是可在不一样的实现之间作移植的，好比Hibernate和TopLink Essentials之间。所以，若是应用没有用到某些提供商特有的功能特性的话，那么移植性就不是什么大问题。

社区支持和文档

在这方面，Hibernate明显是个赢家。存在许多以Hibernate为焦点的论坛，在这些论坛中社区成员都会积极地回答各类问题。关于这一点，iBATIS和JPA正慢慢遇上。

跨非Java平台的移植性

iBATIS支持.Net和Ruby on Rails。Hibernate以NHibernate的形式为.Net提供了一个持久性解决方案。JPA，做为特定于Java的API，显然并不支持任何的非Java平台。

表1给出了这一比较的一个总结。

表1. 持久性解决方案比较

特性	iBATIS	Hibernate	JPA
简易性	优	良	良
完整的ORM解决方案	通常	优	优
对数据模型改变的适应性	良	通常	通常
复杂性	优	通常	通常
对SQL的依赖	良	通常	通常
性能	优	优	不适用*
跨不一样关系数据库的移植性	通常	优	不适用*
非Java平台的移植性	优	良	不支持
社区支持和文档	通常	良	良

*JPA对这些特性的支持取决于持久性提供程序，最终的结果可能会视状况各异。

结论

iBATIS、Hibernate和JPA是用于把数据持久到关系数据库中的三种不一样的机制，每种都有着本身的优点和局限性。iBATIS不提供完整的ORM解决方案，也不提供任何的对象和关系模型的直接映射。不过，iBATIS给你提供了对查询的全面控制权。Hibernate提供了一个完整的ORM解决方案，但不提供对查询的控制权。Hibernate很是的受欢迎，有一个庞大而活跃的社区为新用户提供支持。JPA也提供一个完整的ORM解决方案，并提供对诸如继承和多态一类的面向对象编程特性的支持，不过它的性能则取决于持久性提供程序。

某个特定持久性机制的选择事关全部功能特性的权衡，这些特性在本文的比较章节中都作了讨论。对于大部分的开发者来讲，须要根据是否要求对应用的SQL作全面控制、是否须要自动生成SQL，或仅是想要一个易于编程的完整的ORM解决方案等各方面的考虑来作决定。