[转] hibernate和ibatis的对比
IBATIS:
iBATIS一词来源于“internet”和“abatis”的组合,是一个由Clinton Begin在2001年发起的开放源代码项目,最初侧重于密码软件的开发,现在是一个基于Java的持久层框架。
iBATIS提供的持久层框架包括SQL Maps和Data Access Objects(DAO),同时还提供一个利用这个框架开发的JPetStore实例,相对Hibernate和Apache OJB等“一站式”ORM解决方案而言,ibatis 是一种“半自动化”的ORM实现,iBATIS需要开发人员自己来写sql语句,这可以增加了程序的灵活性,在一定程度上可以作为ORM的一种补充,程序设计人员应该结合自己的项目的实际情况,来选择使用不同的策略。
iBATIS和Hibernate都做了映射,但iBATIS是把实体类和sql语句之间建立了映射关系,这种策略可以允许开发人员自己来写合适的sql语句,而Hibernate在实体类和数据库之间建立了映射关系,sql对于开发人员是不可见的,对于那些数据量非常大的应用,无法去优化sql语句。
所谓“半自动”,可能理解上有点生涩,纵观目前主流的ORM,无论Hibernate还是Apache OJB,都对数据库结构提供了较为完整的封装,提供了从POJO到数据库表的全套映射机制,程序员往往只需定义好了POJO到数据库表的映射关系,即可通过 Hibernate或者 OJB 提供的方法完成持久层操作,程序员甚至不需要对 SQL 的熟练掌握, Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的SQL并调用JDBC接口加以执行。
HIBERNATE:
Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库.
Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任.
Hibernate是一个免费的开源Java包,它使得与关系数据库打交道变得十分轻松,就像您的数据库中包含每天使用的普通Java对象一样,同时不必考虑如何把它们从神秘的数据库表中取出(或放回到数据库表中)
IBATIS和HIBERNATE的比较:
在系统咨询工作过程中,常常遇到以下情况:
1. 系统的部分或全部数据来自现有数据库,处于安全考虑,只对开发团队提供几条Select SQL(或存储过程)以获取所需数据,具体的表结构不予公开
2. 开发规范中要求,所有牵涉到业务逻辑部分的数据库操作,必须在数据库层由存储过程实现(就笔者工作所面向的金融行业而言,工商银行、中国银行、交通银行,都在开发规范中严格指定)
3. 系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标,面对这样的需求,再次举起 Hibernate 大刀,却发现刀锋不再锐利,甚至无法使用,奈何?恍惚之际,只好再摸出JDBC 准备拼死一搏……,说得未免有些凄凉,直接使用 JDBC进行数据库操作实际上也是不错的选择,只是拖沓的数据库访问代码,乏味的字段读取操作令人厌烦,“半自动化”的ibatis,却刚好解决了这个问题,这里的“半自动化”,是相对Hibernate等提供了全面的数据库封装机制的“全自动化”,ORM 实现而言,“全自动”ORM 实现了 POJO 和数据库表之间的映射,以及 SQL 的自动生成和执行,而ibatis 的着力点,则在于POJO 与 SQL之间的映射关系,也就是说,ibatis并不会为程序员在运行期自动生成 SQL 执行,具体的 SQL 需要程序员编写,然后通过映射配置文件,将SQL所需的参数,以及返回的结果字段映射到指定 POJO。
使用ibatis 提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的 Java对象,这一层与通过 Hibernate 实现 ORM 而言基本一致,而对于具体的数据操作,Hibernate会自动生成SQL 语句,而ibatis 则要求开发者编写具体的 SQL 语句,相对Hibernate等“全自动”ORM机制而言,ibatis 以 SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间,作为“全自动”ORM实现的一种有益补充,ibatis 的出现显得别具意义。
IBATIS的优势:
1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
Hibernate 可能需要 3 倍以上的时间来掌握。
2. iBatis 更容易进行 sql 的 优化。
这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。鉴于有的朋友提到了 sql 不太重要。我想在这里强调一下我的经验,一般系统性能的瓶颈都在数据库上。所以这一点是 iBatis 非常重要的一个优势。
3. iBatis 可以进行细粒度的优化
3.1 比如说我有一个表,这个表有几个或者几十个字段,我需要更新其中的一个字段,iBatis 很简单,执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#但是用 Hibernate 的话就比较麻烦了,缺省的情况下hibernate 会更新所有字段。当然我记得 hibernate 有一个选项可以控制只保存修改过的字段,但是我不太确定这个功能的负面效果。
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.3 Hibernate 还有一个方案,就是生成 javabean/map/object[],但是这样的话就可能会产生大量的多余class。map/object[] 的方式应该不错,我比较喜欢这种方式。
3.3 如果我需要更新一条记录(一个对象),如果使用 hibernate,需要现把对象 select 出来,然后再做update。这对数据库来说就是两条 sql。而 iBatis只需要一条 update 的 sql 就可以了。减少一次与数据库的交互,对于性能的提升是非常重要。
4. 开发方面
4.1 开发效率上,我觉得两者应该差不多
4.2 可维护性方面,我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保存sql/hql。
5. 运行效率
5.1 在不考虑 cache 的情况下,iBatis 应该会比hibernate 快一些或者很多(根据实际情况会有所不同)。
当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好,如果你要开发的系统是要在对中数据间移植,那可能用 hibernate 比较好。
2. 缺省的 cache 支持不好,但是 hibernate 的 cache 支持其实也不是很好,而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。
在实际应用中,应该根据不同的应用场景,来选择适合自己的框架。