Ibatis与Hibernate之间的区别汇总

来源:互联网 发布:速录 软件 编辑:程序博客网 时间:2024/05/24 04:01
 

网上有很多关于这两个持久化框架的评论,反正“公说公有理婆说婆有理”,有的人说Ibatis是一种“半自动化”的O/R Mapping,有的人说,它是SQL Mapping。在此,我就摘抄几个版本与大家分享一下啦:

Hibernate简介
Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。
一、基本功能
Hibernate作为数据持久化的中间件,足以让数据库在业务逻辑层开发中去冬眠。它通过可扩展标记语言(XML)实现了类和数据表之间的映射,使程序员在业务逻辑的开发中面向数据库而改为面向对象开发。使整个项目开发分工更加明确,提高了程序开发的效率。
configuration对象:
Configuration 类负责管理Hibernate 的配置信息。Hibernate 运行时需要
获取一些底层实现的基本信息,其中几个关键属性包括:
1. 数据库URL
2. 数据库用户
3. 数据库用户密码
4. 数据库JDBC驱动类
5. 数据库dialect,用于对特定数据库提供支持,其中包含了针对特定数据库特性的实现,如Hibernate数据类型到特定数据库数据类型的映射等。
以上信息一般情况下由hibernate.cfg.xml或者hibernate.properties文件来配置,实现与不同数据库的连接。
Session对象:
Session是持久层操作的基础,相当于JDBC中的Connection:
实例通过SessionFactory实例构建:
Configuration config = new Configuration().configure();
SessionFactory sessionFactory = config.buildSessionFactory();
Session session = sessionFactory.openSession();
之后我们就可以调用Session所提供的save、find、flush等方法完成持久层操作。因此Session对象也封装了所有对数据库的操作来实现Hibernate对数据库的操纵功能,如:
Save()方法实现增加和保存;
Delete()方法实现数据的删除;
Update()方法实现数据更新和修改;
Find()方法实现数据的检索;
Hibernate会根据不同的操作自动生成相应的SQL语句,从而实现了程序员对PO对象的操作转化为对数据库关系表的操作。
二、使用步骤
1.编写Hibernate配置文件
Hibernate配置文件有两种,分别是hibernate.cfg.xml文件和hibernate.properties,推荐使用hibernate.cfg.xml。
2.PO和映射文件
使用middlegen和hibernate-extensions从数据库导出PO的映射文件,并在hibernate.cfg.xml当中声明。
3.编写DAO
对每一张关系表编写一个DAO,提供一组增、删、改、查方法供业务逻辑对数据库操作使用。
更多的细节请大家参阅hibernate的网站获取详细的信息。并在各自的实践和开发中加深体会。
Ibatis简介
相对Hibernate和Apache OJB 等"一站式"ORM解决方案而言,ibatis 是一种"半自动化"的ORM实现。所谓"半自动",可能理解上有点生涩。纵观目前主流的ORM,无论Hibernate 还是Apache OJB,都对数据库结构提供了较为完整的封装,提供了从POJO 到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系,即可通过Hibernate或者OJB 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握,Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的SQL 并调用JDBC 接口加以执行。
Ibatis最直接的好处就是不但为程序员提供了对象与关系数据库之间的映射,同时提供操作方法与SQL间的直接影射,设计者可以直接为一个方法指定一条SQL语句,从而取得更加准确的数据,同时为优化查询、连接查询提供了方便。
一、基本功能
作为又一个轻量级的ORM中间件,ibatis除了提供了对数据库基本的增、删、改、查外还提供了连接管理,缓存支持,线程支持,(分布式)事物管理等一套教为完整的数据库管理功能。
SqlMapClient对象是ibatis持久层操作的基础,相当于hibernate中的session,提供对SQL映射的方法。
insert()方法实现对插入SQL语句的映射;
delete()方法实现对删除SQL语句的映射;
update()方法实现对更新SQL语句的影射;
queryForList()、queryForMap()、queryForObject()、queryForPaginatedList()等方法提供了一组查询SQL语句的影射;
二、使用步骤
1.ibatis SQL Map 配置文件
文件中对所用数据库的连接做了基本配置,包括数据库驱动类型、用户名、密码,以及连接池的相关管理数据。
2.PO和映射文件
和hibernate一样,PO作为数据库关系表的影射,也需要响应的映射配置文件,可以手写,也可以借助hibernate的相关工具生成PO,不会影响PO在ibatis中的使用。与hibernate不同的是,ibatis的映射文件中没有对PO中每个属性做响应的描述,而是指定了一系列与PO有关的SQL相关操作,也体现了ibatis良好的灵活性与可扩展性。
3.编写DAO
在DAO中,可以使用SqlMapClient提供的方法来对应的指定对PO操作的SQL语句,从而使业务逻辑层的开发仍然是面向对象的操作。

选择Hibernate还是iBATIS都有它的道理:
Hibernate的特点:
Hibernate功能强大,数据库无关性好,O/R映射能力强,如果你对Hibernate相当精通,而且对Hibernate进行了适当的封装,那么你的项目整个持久层代码会相当简单,需要写的代码很少,开发速度很快,非常爽。以数据库字段一一对应映射得到的PO和Hibernte这种对象化映射得到的PO是截然不同的,本质区别在于这种PO是扁平化的,不像Hibernate映射的PO是可以表达立体的对象继承,聚合等等关系的,这将会直接影响到你的整个软件系统的设计思路。Hibernate对数据库结构提供了较为完整的封装,Hibernate的O/R Mapping实现了POJO 和数据库表之间的映射,以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系,即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握, Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的SQL 并调用JDBC 接口加以执行。Hibernate的缺点就是学习门槛不低,要精通门槛更高,而且怎么设计O/R映射,在性能和对象模型之间如何权衡取得平衡,以及怎样用好Hibernate方面需要你的经验和能力都很强才行,但是Hibernate现在已经是主流O/R Mapping框架,从文档的丰富性,产品的完善性,版本的开发速度都要强于iBATIS。
iBATIS的特点:
iBATIS入门简单,即学即用,提供了数据库查询的自动对象绑定功能,而且延续了很好的SQL使用经验,对于没有那么高的对象模型要求的项目来说,相当完美。iBATIS的缺点就是框架还是比较简陋,功能尚有缺失,虽然简化了数据绑定代码,但是整个底层数据库查询实际还是要自己写的,工作量也比较大,而且不太容易适应快速数据库修改。当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。
对于实际的开发进行的比较:

我在最初的选型的时候,考虑到iBatis和Hibernate不同,本来打算选择Hibernate的,在研究的过程中发现了iBatis的特性,经过分析比较之后我选择了iBatis。现在我已经使用iBatis 完成了一个中小型的项目。这个项目在性能、可维护性、可扩展性方面都非常令我满意。

在这个过程中我也不断的与使用过或者正在使用Hibernate的人进行过探讨。而且我本身也在不断的跟进Hibernate的发展。

最终,我的结论是iBatis的选择非常正确,而且越用越喜欢它了。

当然了,我对iBatis和Hibernate的理解还是非常有限的,所以这里的关于Hibernate的一些观点的错误之处希望能够得到Hibernate高手的指正。

1. iBatis的特性易于掌握

iBatis的特性拿来文档看半天到两天就可以掌握了。Hibernate可能需要3倍以上的时间来掌握。

2.iBatis的特性更容易进行SQL的优化

这个应该大家都有共识了。另外Hibernate生成的SQL也实在是太难看了。鉴于有的朋友提到了SQL不太重要。我想在这里强调一下我的经验,一般系统性能的瓶颈都在数据库上。所以这一点是iBatis和Hibernate比较后非常重要的一个优势。

3.iBatis的特性是可以进行细粒度的优化

3.1 比如说我有一个表,这个表有几个或者几十个字段,我需要更新其中的一个字段,iBatis 很简单,执行一个SQLUPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用Hibernate的话就比较麻烦了,缺省的情况下Hibernate会更新所有字段。当然我记得Hibernate有一个选项可以控制只保存修改过的字段,但是我不太确定这个功能的负面效果,因此iBatis和Hibernate比较,iBatis的优势很明显。

3.2 我需要列出一个表的部分内容,用iBatis的时候,这里面的好处是可以少从数据库读很多数据,节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE

3.2.1 一般情况下Hibernate会把所有的字段都选出来。比如说有一个上面表有8个字段,其中有一两个比较大的字段,varchar(255)/text。上面的场景中我为什么要把他们也选出来呢?

3.2.2 用Hibernate的话,你又不能把这两个不需要的字段设置为 lazy load,因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出iBatis的好处了。

3.2.3Hibernate还有一个方案,就是生成 javabean/map/object[](感谢 leelun/cjmm),但是这样的话就可能会产生大量的多余 class。map/object[] 的方式应该不错,我比较喜欢这种方式。

3.3 如果我需要更新一条记录(一个对象),如果使用Hibernate,需要现把对象 select 出来,然后再做 update。这对数据库来说就是两条SQL。而iBatis只需要一条 update 的SQL就可以了。减少一次与数据库的交互,对于性能的提升是非常重要。

4. 开发方面

4.1 开发效率上,我觉得iBatis和Hibernate应该差不多

4.2 可维护性方面,我觉得iBatis更好一些。因为iBatis的 SQL都保存到单独的文件中。而Hibernate在有些情况下可能会在 java 代码中保存sql/hql。

5. 运行效率

5.1 在不考虑 cache 的情况下,iBatis 应该会比Hibernate快一些或者很多(根据实际情况会有所不同)。

当然 iBatis和Hibernate相比也有比较大的缺点

1. 不同数据库类型的支持不好,如果你要开发的系统是要在对中数据间移植,那可能用Hibernate比较好。

2. 缺省的 cache 支持不好,但是Hibernate的 cache 支持其实也不是很好,而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。

 

讲到这里,也顺便讲讲Ibatis的七大特性吧:

iBATIS特性有哪些呢?正如你所知道的,可以在任何系统中使用iBATIS。像iBATIS这样一个框架能够使你的应用从架构级别上开始受益是什么原因呢?来开始我们的介绍吧。

iBATIS特性1简单性

iBATIS被广泛认为是当今可用的最简单的持久化框架之一。简单性的理念根植于iBATIS开发团队,它在iBATIS的所有开发目标中居于首位。这种简单性的取得是因为iBATIS直接构建于JDBC和SQL之上。iBATIS对于Java开发者来说非常简单,因为它除了不用编写那么多代码外与JDBC的工作机制非常相像。几乎你知道的关于JDBC的一切都对iBATIS同样适用。你几乎可以这样认为,iBATIS就是以XML的形式来描述的JDBC代码。有人说,iBATIS拥有许多JDBC所没有的架构级的优点,这些优点我们随后就将讨论。iBATIS对于数据库管理员以及SQL程序员来说也非常容易理解。iBATIS配置文件几乎人人都能读懂,只要他有SQL编程的经验。

iBATIS特性2生产效率

任何一个优秀的框架,其目的都是使得框架的使用者能够获得更高的生产效率。一般情况下,框架负责处理公共的任务,减少编写那些像样板一样的重复代码,以及解决复杂的架构级的问题。iBATIS在给开发人员带来更高的开发效率方面做得非常成功。在意大利的Java用户组(Java Users Group)所做的一个案例调查中(参见www.jugsardegna.org/vqwiki/jsp/Wiki?IBatisCaseStudy),Fabrizio Gianneschi发现iBATIS减少了持久层大约62%的代码量。所以能减少如此之多的代码量,究其原因是开发者再不需要编写繁琐的JDBC代码了。SQL语句仍然是硬编码的,不过就像你在本章之前所看到的,SQL不是问题——问题在于JDBC API,对于ADO.NET而言也是如此。

iBATIS特性3性能

性能这个话题无疑会引起框架开发者、框架使用者以及商业软件开发商之间的一场激烈争论。事实是,从一个较低的级别来看这个问题,无疑所有的框架都会带来一定的性能损失。一般来说,如果你比较硬编码的JDBC代码和iBATIS代码,做一个1,000,000次的for循环,你会发现JDBC在性能上的确有一些优势。幸运的是,在现代应用开发中,以上这样的for循环带来的性能损失并不重要。真正重要的是,你如何从数据库中获取数据,何时获取,获取的频率又是多少。例如,分页查询之所以能大大提高应用的性能就在于,它不会将可能成千上万条的记录从数据库中一次取出。同样地,使用像懒加载这样的特性可以避免加载那些在当前情况下并不需要的数据。另一方面,如果你确定需要加载一份复杂的对象图,涉及到来自多个表的大量数据,如果能仅用一条SQL语句就完成所有对象的加载显然可以大大提高效率,iBATIS支持使用这样的SQL语句。iBATIS支持许多性能优化措施,我们将在本章之后的章节中详细讨论。就目前而言,最重要的是要知道iBATIS总是能通过一种简单的方式来配置和使用,其性能与JDBC相当,甚至更好。另一个需要重点考虑的问题就是,并不是所有的JDBC代码都是编写良好的。JDBC API非常复杂,编写正确的代码需要非常小心。不幸的是,大量的JDBC代码都编写得相当糟糕,因此从较低层次上看甚至还没有iBATIS工作得好。

iBATIS特性4关注点分离

在典型的JDBC代码中,在应用的各个层中都能找到与数据库相关(例如获取连接、遍历结果集)的代码,这并不稀奇。相信大家都见过甚至开发过这样糟糕的应用——所有的逻辑都在一个JSP页面中完成,连接数据库、执行SQL语句,遍历结果集,当然还有散落其间的HTML代码。这样的代码简直是一个噩梦。在第一章中我们已经讨论了对应用分层的重要性。我们已经看到了如何从一个较高的角度对应用分层,以及持久层内部又是如何进一步分层的。iBATIS通过帮助管理所有这些持久化相关的资源来支持分层,这些资源包括数据库连接(database connection)、prepared statement以及结果集(result set)。iBATIS提供了一组数据库无关的接口以及API,使得应用的其它部分能够通过使用这组接口和API保持与数据库相关资源的独立性。使用iBATIS,你的代码总是在直接与严格的对象打交道,再也不用管那些随意的结果集了。iBATIS实际上使得你难以违背对应用分层这样的最佳实践。

iBATIS特性5明确分工

一些数据库管理员是如此热爱他们的数据库,以至于不愿意让任何其他人来为数据库编写SQL。而有一些人又是如此擅长编写SQL,以至于其他人都想让他们来做这项工作。无论是什么原因,在你的开发团队中实现人尽其才总是有利的。如果你的团队中有人尤其擅长于编写SQL,但是对于Java或C#却不那么在行,那么就可以让他们专门编写SQL。iBATIS使得这种分工成为可能。因为在iBATIS中,SQL语句在很大程度上同应用的源代码是分离的,SQL程序员可以按照SQL原本的方式来编写它,而不必担心有关SQL字符串连接的问题。即使由相同的开发者来编写Java代码和SQL,在数据库性能调整(performance tune)的过程中也会有一个来自DBA的常见请求,即“显示出SQL”。用JDBC来完成此事并不容易,因为SQL隐藏得很深,是连接一堆分散的字符串得到的,甚至还可能是在递归语句和条件语句中动态地创建的。如果使用对象关系映射,情况就更加复杂了,因为你通常必须运行应用然后才能log出这些SQL语句,即使你找到了它们,你也根本不能改变它们。iBATIS则提供了充分的自由,使得任何人都可以开发、观察并且修改在数据库中执行的SQL语句。

iBATIS特性6可移植性

iBATIS是可移植的。由于它相对简单的设计,它几乎可以用任何一种语言在任何一个平台上实现。书写本书时,iBATIS支持3种最受欢迎的开发平台:Java、Ruby和微软.NET的C#。

当前,配置文件并不完全跨平台兼容,但是我们正在计划使它们更加兼容。重要的是,概念和方法都是可移植的。这就使你能够保证你所有的应用在设计上是一致的。和其他框架相比,iBATIS可以处理更多语言以及更多类型的应用,而无需考虑应用设计的不同。如果应用的一致性对于你来说很重要的话,使用iBATIS就可以很好地帮你达到一致性。

iBATIS特性7开源和诚实

开始时我们说本节有“自吹自擂”之嫌。事实上,iBATIS是免费的开源软件。无论你是否使用它,我们都不会因此而获得哪怕是一分钱的利益。你已经买了本书,所以我们已经获得了我们该得的利益。开源软件的最大的优点之一就是诚实。我们没有任何理由对你撒谎。因此下面我们将要做的事在商业软件文档中就是非常罕见的:我们将要讨论一些你可能不应该使用iBATIS的情况,并且提出一些合适的替代方案。

iBATIS特性就向你介绍到这里,希望通过这样的讲解使你更加清楚的认识iBATIS。