Hibernate和Ibatis

1.出身 

hibernate 是当前最流行的o/r mapping框架，它出身于sf.net，现在已经成为jboss的一部分了。 

ibatis 是另外一种优秀的o/r mapping框架，目前属于apache的一个子项目了。 

 

2.原理 

相对hibernate“o/r”而言，ibatis是一种“sql mapping”的orm实现。hibernate 对数据库结构提供了较为完整的封装，hibernate的o/r mapping实现了pojo 和数据库表之间的映射，以及sql 的自动生成和执行。程序员往往只需定义好了pojo 到数据库表的映射关系，即可通过hibernate 提供的方法完成持久层操作。程序员甚至不需要对sql 的熟练掌握， hibernate/ojb 会根据制定的存储逻辑，自动生成对应的sql 并调用jdbc 接口加以执行。 

而ibatis 的着力点，则在于pojo 与sql之间的映射关系。也就是说，ibatis并不会为程序员在运行期自动生成sql 执行。具体的sql 需要程序员编写，然后通过映射配置文件，将sql所需的参数，以及返回的结果字段映射到指定pojo。 

 

3.机制 

使用ibatis 提供的orm机制，对业务逻辑实现人员而言，面对的是纯粹的java对象。这一层与通过hibernate 实现orm 而言基本一致，而对于具体的数据操作，hibernate会自动生成sql 语句，而ibatis 则要求开发者编写具体的sql 语句。相对hibernate而言，ibatis 以sql开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。 

 

hibernate与ibatis的对比： 

 

4.学习成本 

ibatis非常简单易学，hibernate相对较复杂，门槛较高。 

 

5.开源软件 

二者都是比较优秀的开源产品 

 

6.二次开发 

当系统属于二次开发,无法对数据库结构做到控制和修改,那ibatis的灵活性将比hibernate更适合 

 

7.海量数据 

系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的sql语句（或存储过程）才能达到系统性能设计指标。在这种情况下ibatis会有更好的可控性和表现。 

 

8.自动化程度 

ibatis需要手写sql语句，也可以生成一部分，hibernate则基本上可以自动生成，偶尔会写一些hql。同样的需求,ibatis的工作量比 hibernate要大很多。类似的，如果涉及到数据库字段的修改，hibernate修改的地方很少，而ibatis要把那些sql mapping的地方一一修改。 

 

9.与数据映射关系 

ibatis以数据库字段一一对应映射得到的po和hibernte这种对象化映射得到的po是截然不同的，本质区别在于这种po是扁平化的，不像hibernate映射的po是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。 

 

10.技术支持 

hibernate现在已经是主流o/r mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于ibatis 

 

最关键的一句话是ibatis的作者说的： 

if you are starting a new project and you're in full control of your object model and database design, hibernate is a good choice of o/r tool. 

if you are accessing any 3rd party databases (e.g. vendor supplied), or you're working with a legacy database, or even just a really poorly designed database, then an o/r mapper might not be capable of handling the situation. that's were an sql mapper comes in handy 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ibatis:sql需要自己写

hibernate: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会有更好的可控性和表现。

对于实际的开发进行的比较：

1． iBATIS需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些Hql。同样的需求,iBATIS的工作量比 Hibernate要大很多。类似的，如果涉及到数据库字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。

2. iBatis 可以进行细粒度的优化

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

例如：我需要列出一个表的部分内容，用 iBatis 的时候，这里面的好处是可以少从数据库读很多数据，节省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...一般情况下Hibernate 会把所有的字段都选出来。比如说有一个上面表有8个字段，其中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他们也选出来呢？用hibernate 的话，你又不能把这两个不需要的字段设置为lazy load，因为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出ibatis 的好处了。如果我需要更新一条记录（一个对象），如果使用 hibernate，需要现把对象 select 出来，然后再做 update。这对数据库来说就是两条sql。而iBatis只需要一条update的sql就可以了。减少一次与数据库的交互，对于性能的提升是非常重要。

3. 开发方面：

开发效率上，我觉得两者应该差不多。可维护性方面，我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保sql/hql。相对Hibernate“O/R”而言，iBATIS 是一种“Sql Mapping”的ORM实现。 而iBATIS 的着力点，则在于POJO 与SQL之间的映射关系。也就是说，iBATIS并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。使用iBATIS 提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM 而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL 语句，而iBATIS 则要求开发者编写具体的SQL 语句。相对Hibernate而言，iBATIS 以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。

4. 运行效率

在不考虑 cache 的情况下，iBatis 应该会比hibernate 快一些或者很多。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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。

在实际应用中，应该根据不同的应用场景，来选择适合自己的框架。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 1. 库表关系的复杂度，首先取决于需求，不取决于设计，设计能力强的人，也要遵守库表设计的规范，从巴克斯三个范式上，原则上也要遵守。不能说用了Hibernate,自己的库表设计能力就强了。不能为了用Hibernate，就去一味批判复杂的关系不对。复杂的关系设计对不对，首先取决于是否有复杂的需求，其次才取决于设计者的能力。

    2. 只要你用的是关系数据库，就必须要明白，为什么叫关系数据库，而不叫面向对象数据库，把面向对象的那些观点，拿到库表设计上，后期维护和调优上，你要担起责任，不能让开发人员替早期决策人员擦屁股。我见过有的人，打着OO和扩展性的旗号，硬生生的把一个表，拆成了三个表，而这三个表，本来，只需要增加一个类型字段，再做一些冗余，就可以是一个表。现在查询时，还要把这三个表Union到一块来查。当需求变更时，增加一个字段，不仅要改变三个类，还要改变三个表。

    3.One-One的库表设计，对于DBA来讲，并不是一个best practice的设计。不能为了Hibernate，刻意把大表拆成小表，再用几个小类，做成One-One的映射关系。整体性，是不能随便的分割，毕竟开发人在调试、测试和维护的时候，更喜欢看数据库里的数据，本来一个SQL，就查出来，现在要到多个表中去查。

    4. 增删改存的实体维护

       Ibatis比不上Hibernate，说实在话，现在让我写SQL来维护一个多对多关系的实体维护，我都要考虑上半天，别说写代码了。

    5. 你需要写原生SQL吗

       首先你要确认，你项目的要求不需要写原生SQL，再来讲Ibatis和Hibernate的好坏，在写原生SQL上，特别是动态生成的SQL，ibatis比Hiberante有得一拼，ibatis就像一个模板一样，将SQL写在配置文件当中，集中配置，特别方便技术领导者监控项目成员写的SQL好坏，而且没有什么学习曲线，就写SQL就完事了。

       有人会说，Hibernate也支持写SQL，但是写代码当中，就失去了原来基于Hibernate的DAO的简洁性。那个DAO一点也不简洁，如果你将动态拼SQL的代码也放在DAO当中，那个DAO就会充斥大量的If 。。Else。。之类的语句，一坨一坨的，非常的壮观。

       还有人会说，Hibernate也支持命名查询，将SQL写在映射文件当中，但是命名查询，只支持占位符固定的情况，也就是说，where a = ? and b = ? and c=?，是三个问号，就是三个问号，传参时，少一个都不行。但是很多项目的查询，都是动态的，也就是说用户选了这个查询条件，才会生成这个占位符的。

       Hibernate办不到。

 

       还有人会说，我自己用Hibernate写一个框架，也可以做到，那你写的绝对可能比Ibatis好，也可能差，你要造轮子，谁来拦不着。

  

    5. 调优

       早期调优，有些Bad SQL，其实在code review阶段，只要看看Ibatis的SQL配置文件，就可以扼杀掉的，如果使用HSQL，可能不会被发现，因为它不仅隐藏在代码当中，有的时候，还需要程序跑起来，通过日志打印出SQL或者通过其它工具如P6Spy来看的出来。

       后期调优，既然是后期调优，我想就一定是遇到了瓶颈，可能要在库表上做冗余，可能要检查那些Bad SQL，可能要修改代码，可能要动用DBA层次上的一些调优手段，那么调优越深入，Ibatis的优势就越能体现出来，比如说增加临时表，中间表，增加冗余字段等。

    6. 开发速度

       如果项目当中，没有一个Hibernate高手，你的项目又相对的复杂，不仅有复杂的库表关系，还有大量的报表查询，那么使用Hibernate，速度上逊于Ibatis.

       问题在于，怎么样算是一个Hibernate高手，别看论坛上，那么多人，群情激奋的在说Hibernate的好，有谁真的是高手？

     7. 平台移植性

       如果你的项目要做产品，而且打算基于多个数据库平台的发布，使用Hiberante是没有说了。

    8. 维护性

       如果不考虑移植性，Ibatis的可维护不差于Hibernate，库表变动引起实体类变动时，HSQL也会有改动，有人说不用改，说这话的那个人可能整天只会有select * ，如果ibatis也是这样写，也不用动了。

       HSQL好阅读吗，From order，确实很简单，但实际当中，这跟拿HelloWord做例子，有什么区别？

     

   

    9. 我在实际项目当中的运用

    项目背景：

       我自己从Hibernate2开始使用，我现在也不认为我是Hibernate高手，我也没有时间去钻研Hibernate，更深的东西，我也不喜欢坐在开发人员旁边老半天，去帮他们解决Hibernate遇到的问题，因为我自己还有很多事要做。

       我的项目当中，在Hibernate方面，还有一个比我更强的人，他也很烦去看Hibernate打印出来的sql，看上老半天，再调上老半天，项目进度，嗖嗖的过去了。

       水平越高的人，任务越重，很少有时间和耐心去解决一般性的问题。

    最终的运用：

       在基于Spring的容器事务管理之下，

       增、删、改、存及在事务中的查询，使用Hibernate。

       非事务性的查询及报表，都用Ibatis，维护非常的直观方便，开发速度上也快很多。

       我觉得现在技术换代很快，使用一项技术，首先是要快速的解决问题，然后要学习他的思想，那些整天死抱着Hibernate，自认为学习到ORM的设计技巧的人，就去继续的学吧。

       我已经会用Hibernate的一些方面，我觉得够用就行了，犯不上，天天钻研HSQL，如果有时间，我觉得躺在草坪上看看Unix的编程艺术，看看代码大全，看看Oracle的编程艺术，比看Hibernate的SB书要惬意多了。

       简单能够带来快乐，用过EJB，再用Spring的人，都有体会，那简直是一种思想上的重生。

 

       Ibatis的设计者认为，在新的项目当中，可以使用Hibernate，在旧的遗留项目当中，可以使用Ibatis，不明白，他为什么说这样的话，这与新旧项目有什么区别？ 用不用Ibatis，我觉得对我上面说的几点有关。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

项目也做过几个, 使用IBatis就做一个项目, 基本上都是使用Hibernate, 也只是知道几点关于这两个框架的区别, 今天闲着没事干, 从网上找了几篇文章, 做了一个简单的整理。网上关于这两个框架的比较也很多, 只是自己想把别人的东西拿过来整理一下, IBatis和Hibernate的比较。(非原创)

 

Hibernate  VS  iBATIS

 

简介

Hibernate是当前最流行的O/R mapping框架，当前版本是3.05。它出身于sf.net，现在已经成为Jboss的一部分了。

iBATIS是另外一种优秀的O/R mapping框架，当前版本是2.0。目前属于apache的一个子项目了。

相对Hibernate"O/R"而言，iBATIS 是一种"Sql Mapping"的ORM实现。

Hibernate对数据库结构提供了较为完整的封装，Hibernate的O/R Mapping实现了POJO和数据库表之间的映射，以及SQL的自动生成和执行。程序员往往只需定义好了POJO到数据库表的映射关系，即可通过Hibernate提供的方法完成持久层操作。程序员甚至不需要对SQL的熟练掌握，Hibernate/OJB会根据制定的存储逻辑，自动生成对应的SQL并调用JDBC接口加以执行。

而iBATIS的着力点，则在于POJO与SQL之间的映射关系。也就是说，iBATIS并不会为程序员在运行期自动生成SQL执行。具体的SQL需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。使用iBATIS提供的ORM机制，对业务逻辑实现人员而言，面对的是纯粹的Java对象，这一层与通过Hibernate 实现ORM而言基本一致，而对于具体的数据操作，Hibernate会自动生成SQL语句，而iBATIS则要求开发者编写具体的SQL语句。相对Hibernate而言，iBATIS以SQL开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。

二者的对比：

1．  iBATIS非常简单易学，Hibernate相对较复杂，门槛较高。

2．  二者都是比较优秀的开源产品。

3．  当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合。

4．  系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。

5．  iBATIS需要手写sql语句，也可以生成一部分，Hibernate则基本上可以自动生成，偶尔会写一些Hql。同样的需求,iBATIS的工作量比Hibernate要大很多。类似的，如果涉及到数据库字段的修改，Hibernate修改的地方很少，而iBATIS要把那些sql mapping的地方一一修改。

6．  以数据库字段一一对应映射得到的PO和Hibernte这种对象化映射得到的PO是截然不同的，本质区别在于这种PO是扁平化的，不像Hibernate映射的PO是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。

7．  Hibernate现在已经是主流O/R Mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于iBATIS。

8．  最关键的一句话是iBATIS的作者说的：

If you are starting a new project and you're in full control of your object model and database design, Hibernate is a good choice of O/R tool.

If you are accessing any 3rd party databases (e.g. vendor supplied), or you're working with a legacy database, or even just a really poorly designed database, then an O/R mapper might not be capable of handling the situation. That's were an SQL Mapper comes in handy

 

结论:

Hibernate和iBATIS可以说是互相补充,共同发展的关系.具体你想用什么要看实际情况.如果看了上面的文字还是拿不定注意,那就Just to try it.实践是检验真理的唯一标准.鞋合不合适,只有试了才知道。

 

说明：本文转自：http://blog.csdn.net/hero272285642/archive/2008/04/25/2327887.aspx

 

 

选择Hibernate还是iBatis?

选择Hibernate还是iBATIS都有它的道理： 

Hibernate功能强大，数据库无关性好，O/R映射能力强，如果你对Hibernate相当精通，而且对Hibernate进行了适当的封装，那么你的项目整个持久层代码会相当简单，需要写的代码很少，开发速度很快，非常爽。 

Hibernate的缺点就是学习门槛不低，要精通门槛更高，而且怎么设计O/R映射，在性能和对象模型之间如何权衡取得平衡，以及怎样用好Hibernate方面需要你的经验和能力都很强才行。 

iBATIS入门简单，即学即用，提供了数据库查询的自动对象绑定功能，而且延续了很好的SQL使用经验，对于没有那么高的对象模型要求的项目来说，相当完美。 

iBATIS的缺点就是框架还是比较简陋，功能尚有缺失，虽然简化了数据绑定代码，但是整个底层数据库查询实际还是要自己写的，工作量也比较大，而且不太容易适应快速数据库修改。 

我的建议就是： 

如果你的团队没有Hibernate高手，那么请用iBATIS，要把Hibernate用好，并不容易；否则你应该选择Hibernate，那样你的开发速度和代码简洁性都相当棒！ 

我觉得rails的ActiveRecord是平衡性做的最好的，避免了Hibernate的复杂性和学习HQL的成本，同时具备iBATIS即学即用的简单性。

 

说明：本文转自：http://robbin.javaeye.com/blog/24529

 

我为什么选择 iBatis而不是 Hibernate(对于正在选型的人的建议)

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[](感谢leelun/cjmm)，但是这样的话就可能会产生大量的多余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。

 

 

 

hibernate与ibatis比较的11大优势 

Hibernate在解决性能问题方面做得非常好。有了它的缓存机制，使用第三方缓存和数据库连接池，就较好的解决的性能问题。但这些还不够，hibernate给了开发者足够的自由，让开发者自己去控制性能问题。

学习了一段时间的ibatis，我觉得hibernate有着ibatis无法替代的优势。

1、开发者都知道，hibernate让我们以oo的方式操作数据库，这让我们看到了hibernate的强大之处，体验到操作数据的方便。但Gavin King说，hibernate最耀眼之处是hibernate的缓存机制，而不是以oo的方式操作数据库。Hibernate的缓存机制不外乎是一级缓存session，二级缓存sessionFactory，和第三方缓存如ehcache。也就是hibernate的最强大的地方是它的缓存，理解了这个才能真正的理解hibernate。缓存实在太难了，我至今未能真正理解。

2、可维护性：ibatis宣扬写sql语句，它将sql语句放进一个单独的xml文件，这种方式赢得了很多开发者的喜爱，一句话，方便维护。但hibernate同样具有这种功能，而且比ibatis更加强大。Hibernate的命名查询/命名参数查询，就是将hql语句放在一个单独的xml文件之中，它仍然让人们以面向对象的方式去操纵数据，这得到大量遵循 oo方式开发者的喜爱，而不用在以oo的方式写着代码的同时，然后再转变思维，用面向关系的方式去写那些sql语句。但hibernate不仅做了这些， 它的native sql查询方式，完全满足sql语句的偏爱者，它像ibatis一样，将sql语句放在配置文件之中。

3、性能：我坚信，hibernate性能问题不是问题。想想那么多大中小项目都在使用hibernate，你还怀疑hibernate的性能吗？spring整合hibernate之后，在真正性能瓶颈的地方，完全可以使用spring集成的jdbc，或直接写存储过程得了。但首先得确认，这实在是性能瓶颈的地方，我想，不应想当然的认为性能的问题，所谓的性能问题阻挠了很多人。我认为，性能的好坏无外是发送sql语句的多少而已。性能好，发送的sql语句少，性能差，就是发送大量的sql语句。Hibernate在解决性能问题方面做得非常好。有了它的缓存机制，使用第三方缓存和数据库连接池，就较好的解决的性能问题。但这些还不够，hibernate给了开发者足够的自由，让开发者自己去控制性能问题。

我认为开发者可以在以下几个方面自行调优：

a、在查询字符串中，应该总是使用jdbc的占位符？，或使用使用命名参数：，不要自查询中使用字符串值来代替非常量值。

b、Flush会影响性能，频繁刷新影响性能，尽量减少不必要的刷新。

c、Cascade策略，在几对几的关系，正确设置cascade策略，想清楚在操作对象A的同时是否需要级联操作对象B，比如在one to many的父子关系中，删除了父亲one，需级联删除子many，这时的one这端可设置cascade="delete"，这样在删除one时，会自动删除子，但对子的操作不会影响父。Cascade还有其他的属性值，只要设置正确，可提升性能。

d、lazy策略，正确设置延迟加载策略同样会提升性能，在one to many或many to many中，通常总应该延迟加载many的一方的到内存。设置了lazy="true"，首先发送sql语句，加载自己到内存，到需要时才加载级联对象；lazy="false",则会同时加载自己和级联对象到内存。

e、另外还有集合的性能(set、list、map、array)，都应正确设置。

f、正确使用第三方缓存，在读操作频繁写操作不多的情况，使用第三方缓存可大幅度提升性能，如ehcache的缓存策略有：read-only，read-write和notstrict-read-write。

f、 随着hibernate新版本的发布，和技术的发展，我相信hibernate的性能会越来越好，所有性能不是不使用hibernate的原因。

4、hibernate不仅仅作为持久层的orm框架存在，它除了dao层的持久化操作外，还有很多。

在注解annotation已经走向主流的今天，hibernate 迅速响应，让xml部署描述符成为可选的。Hibernate annotation对大字段的处理只是一个@Lob就搞定了。

hibernate search对Lucene进行了轻量级的封装，全文检索变得非常简单。

Hibernate validator被认为是最合理的验证方式，将验证策略直接附在贯穿各层的领域模型domain上，不再需要哪些web框架的xml方式的验证，代码中不再出现大量的非空/null的判断。

5、jbpm，Jbpm业务流程引擎的持久层采用hibenrnate来实现，要想使用jbpm，hibernate是必须的。我想，业务流程管理无比重要，在SOA迅速发展的今天，如果实施SOA项目，业务流程管理是必然和必须的。因为soa就是业务和it技术的融合，是业务流程管理和it基础架构的融合。在soa中，业务管理是第一位的，这需要相应的技术来实现该业务流程管理。开源领域的jbpm我想会是首选。所以，为了将来有可能实施soa项目，为了实现soa的业务流程管理，应该使用hibernate。

6、大家都知道，hibernate将ejb2时代的实体bean赶进了历史，而ejb3的jpa标准也只不过是hibernate的子集而已。jsr规范请求的威力是巨大的，没有各种jsr规范请求，就不会有各种应用程序框架，各种应用程序框架只是那些jsr规范请求的实现者。jpa作为持久层的规范标准，引导持久层orm框架的方向，jpa同样以面向对象的方式操作数据库，而不是写sql语句。规范标准都完全orm，不写sql了，你还有理由不跟着它吗？

7、Spring+hibernate+范型+可变参数，这是一个非常强大的组合，对应普通的crud操作，你不再需要重复写那些烦人的相似的dao层和manager层的代码，仅仅需要写一次，就完成了所有大量的crud操作。Ibatis尽管也支持范型，但始终没有hibernate支持的好

8、Jboss，hibernate是jboss的项目，jboss的所有项目的持久层都采用的hibernate，要知道，jsr规范组的专家们大多数是来自jboss的，在一定程度上说，jboo引领着java的发展方向。使用hibernate，跟着jboss，不偏离java的发展方向。

9、Gavin King，我最崇拜的偶像，他不仅发明了强大的hibernate，还搞出了同样强大且优雅的web2.0应用程序框架seam。他是ejb3.0专家组成员之一，是jpa规范请求的领导者，他java领域最有发言权、最权威的领袖人物之一。现在，他领导web bean的，jsr299的发展，web bean规范的制定，全球软件巨头如ibm、oracle、bea和apache没有一个反对，纷纷响应。Web bean，想象起来，实在太美好了，完全的松耦合和强类型，所有的应用组件生活在一个应用组件上下文context中，相互合作。那时将不再有各种各样的上下文环境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有hibernate 的session，不再有持久化上下文，不再有事务上下文，不再有安全上下文，所有组件生活在一个大家庭中，大家其乐融融，实现天下的大和平。

10、 osgi，我认为现在最值得学习的一个技术，有了osgi，实现真正的多模块开发，改变传统的开发方式。现在，已经有了hibernate osgi，spring dynamic modul(osgi),struts 2同样实现了对osgi的支持。目前，eclipse是基于osgi开发的，ibm的websphere v6.1，bea的所有产品都重构在osgi上，spring的应用服务器同样基于osgi，在EclipseCon2007上，osgi成为了主要的话题。Osgi受到如此的待遇，一点不奇怪，因为他具有无比强大的功能，改变传统的软件开发方式。Osgi采用树设计模式，将一个项目分成多个模块(bundle)，每个模块单独部署，单独运行，说白了，就是将一个工程分成许多的插件，每个插件单独开发，重复使用，实现完全的即插即用。太令人激动了。如果公司的软件开发基于osgi，将会有大量的重复使用的osgi bundles，公司将会积累大量的无形资产，软件开发将会越来越快。而ibatis现在还没见到对osgi的支持。

11、hibernate的社区非常繁荣，ibatis则相对平静。

综述，hibernate还有很多优秀的特点，只是我们不知道。Hibernate与ibatis，就像大家闺秀对小家碧玉，大家闺秀不仅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有发展前途。小家碧玉尽管也很有魅力，但始终比上大家闺秀。

Hibernate所做的不仅仅是dao层的持久化工作，而ibatis恰恰如此。

选择hibernate，选择orm的王者，选择更全面的工作体验，选择更高效的工作方式，选择更多的利润；选择Gavin King，跟着领袖走；选择jboss，追随开源的潮流，不偏离java的发展方向。

一切都不是借口。一切都在发展，hibernate会越来越好。

 

本文来自:http://blog.sina.com.cn/s/blog_4adc4b0901010kcx.html

 

 

 

Hibernate与IBatis的优缺点及可行性分析

 

1.优点

简单：

易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

实用：

提供了数据映射功能，提供了对底层数据访问的封装（例如ado.net），提供了dao框架，可以使我们更容易的开发和配置我们的dal层。

灵活：

通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。

功能完整：

提供了连接管理，缓存支持，线程支持，（分布式）事物管理，通过配置作关系对象映射等数据访问层需要解决的问题。提供了dao支持，并在dao框架中封装了ado.net，Hibernate和datamapper.增强系统的可维护性：通过提供dal层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。

2.缺点

滞后性：

还没有明确对。net2.0的支持。最新版本在2.0下编译可以，但有些单元测试不能通过。

不成熟，工程实践较少：ibatisnet在实际项目中的使用较少。只是理论上可行。

半orm，工具支持较少：需要我们自己写sql，并且。net下还未发现可以自动生成业务层类和配置文件的工具，这点和Hibernate不一样，Hibernate会为我们的数据库直接产生sql，并有一些辅助工具。因此使用ibatis比Hibernate要多做一些工作。

3.可行性

没有最好的框架，只有最适合的框架。存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。

上面说了部分的ibatis的优点和部分缺点。这些优点从理论上证明ibatis对任何数据持久层都合适，但未必是最好的选择。下面对上面的优缺点分别从两方面讨论。

简单：

我们都喜欢简单，简单意味着学习成本低，使用中出错的可能性低。同时，简单的东西一般来说功能不够强大。反过来，复杂的东西学习成本高，用起来不方便，并且团队没有很强的技术实力，一般不要使用。

实用：

解决了项目中需要解决的问题，这是任何实际工程中采用的框架和工具都应具有的性质，否则就不要拿到实际项目中来。

灵活：

灵活有两层意思，一种是简单易扩展，另一种是功能强大提供了很多选项。ibatis属于前者，Hibernate属于后者。两者各有优缺点。

功能完整：

ibatis的功能完整也是相对的，比我们自己开发的框架应该完整，但对比其他框架肯定也有一些解决不了的问题。

增强系统的可维护性：利用ibatis可以做到sql和代码分离，可以设计出一个清晰的数据访问层（dal）。但项目架构是否科学合理，是否以维护，关键 不在ibatis，因 为它只是一个数据层框架。但是我们也不得不清楚，要想发挥ibatis的优势，我们需要做一些额外工作，比如最好设计dao接口，需要将业务层实体和对实 体的访问放在不同的工程中，同时需要维护xml配置文件。

滞后性：

ibatis组现在还没有提到要支持。net2.0，很多人在。net2.0下使用ibatis都出现了问题。所以如果要使用。net2.0开发，ibatis不是一个好选择，还需要等待。

不成熟：

开源的东西很难说成熟，但一般比我们自己写的框架要成熟。由于我们可以拿到他的源代码，所以关键在于我们能否驾驭它。

半orm，工具支持少：

这注定了ibatis不能从本质上提升开发效率，我们需要自己写sql，写实体类，写配置文件。但这也是它优越的地方，它没有为我们做的他多，所以我们就 有更多的施展空间。而且它非常适合那些并不能完全控制数据库的系统和需要利用数据库本身提供的高级特性的统计查询系统的开发。

使用ibatis需要自己写sql，由于我们的sql不可能完全符合sql标准，比起Hibernate产生的sql来，可移植性差。不过由于我们更改 数据库的可能性较小，对我们来说sql符合标准以便可以在迁移到不同服务器时代价最小并不是十分必要的。另一方面，Hibernate虽然可以屏蔽很多 数据库间的不同，但是却很难利用某些数据库的高级特性，比如oracle的分析统计函数。

Hibernate不适合数据库模式不规范，约束不完整，需要大量复杂查询的系统，同时Hibernate的学习成本较高，完全掌握Hibernate也较困难，风险较大。

自己写框架未必比ibatis的好，稳定，强大和可扩展。而且自己开发框架也需要较大的工作量。

如果使用dotnet并且要选一个数据层框架，而系统中有相当一部分较复杂的sql，或数据库设计不合理，脏数据多，对性能和资源要求严格，ibatis是一个比较不错的选择。他的那些缺点并不是致命的，而且也是有一些解决方案的。尤其是，当选用了ibatis的dataaccess作为dao框架时，我们可以同时使用Hibernate，ado.net和datamapper（ibatisnet的核心组件），那样将会使风险降到最低，并且整个系统的框架比较合理。

另外，利用ibatis可以统一编码风格，节约开发成本，大家不会再把精力浪费到分页 连接池 主键生成等地方了，可以集中精力进行业务组件的编写。

综上：很多时候我们要在是自己开发框架和选用第三方框架和选用什么样的框架问题上进行综合考虑。考虑的标准当然是项目的当前情况和我们希望达到目的的一个平衡。

ibatis只是封装了数据访问层，替我们做了部分的对象关系映射。但我们的代价是必须要写xml配置文件，相对于Hibernate我们还要写很多 sql.Hibernate通过工具直接从数据库模式生成实体类和基本的配置文件，而且大部分情况下不需要我们写sql，会较大的提升开发效率。但这些也 有很多的局限性，尤其是对环境的要求较高（数据库设计，对象设计，团队的协作等）。

个人感觉ibatis对项目比较有意义的地方在于它小巧灵活，可扩展，封装了数据访问层（事务，缓存，异常，日志），并提供了dao框架支持。

利用ibatis我们可以做到代码和sql的分离，只要sql能够解决的问题，ibatis就能帮我们较容易的解决，同时也使我们的项目对某一框架的依赖性变小（因为ibatis是非侵入性的）。这将极大的降低项目风险，减少解决复杂问题的时间，使项目的维护变得简单。

ibatis对于应用的修改，调试，扩充和维护将会变得容易自然。修改时，我们主要修改的是代表模型的实体对象，xml配置文件中的sql，和/或配置文 件的resultmap（很多时候是不需要的）。同时，sql和代码分离，我们不用在代码的stringbuffer的append方法之间寻找需要修改 的sql.配置文件中的sql便利了我们的调试和对sql的评审及以后的sql重用。

利用一些框架在前期一般会拖慢开发效率。因为我们需要付出学习成本，很多时候，使用框架需要写很多配置文件，在使用不熟时开发速度较慢；同时利用框架往往 使系统代码量增大，比如model1和model2模型，开发效率应该还是model1快，四层的架构肯定比两层的代码量大。但对于中后期开发和维护将会极大的提高效率。

利用一些较完全的开发框架和代码生成工具，在前期会较大的提高开发效率，但在后期常常会拖慢进度，并有可能成为以后维护的梦魇。比如torque生成实体类和其对应的sql，虽大幅提高了效率，但修改负担较大。

比较理想的开发方式是使用简单框架结合简单的代码生成工具。框架提供系统的基础服务，并规范开发。框架一方面提供了开发中某一方面的开发基础支持，比如数 据访问层，事务，日志，公用类，异常等。另一方面，也为开发定义了模式，定义了系统的基本轮廓。同时，通过简单的代码生成工具生成部分低级的代码。比如通 过工具从数据库模式生成实体类。这些类生成后我们可以自由修改。

Hibernate是十分强大，比较完善的orm框架，不过这是它的优点也是它的缺点。J2EE系统是否采用Hibernate3，是一个需要认真评估的问题。

要想Hibernate工作的好，数据库的设计必须好。同时对于复杂的数据操作同时需要使用sql，Hibernate3对于直接使用sql的支持比Hibernate2要自然，这一点是可以接受的。

Hibernate比较复杂，功能强大而灵活，要用好Hibernate确实不是很简单，当然spring框架提供了对Hibernate的封装，使Hibernate的使用变得简单了点。

可以说ibatis在任何系统里都适用，但未必是最好选择。不过ibatis提供的思路是我们应该仔细考虑的。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

本文旨在提供一些真实的数据，供那些选择Hibernate3还是MyBatis做持久层的开发人员一个参考。数据在选择的时候，会删除一个最大值和最小值。 

 

1.从代码的编写量 

二者实现相同的功能： 

Hibernate3持久层用了207行Java代码，14行映射文件，18行Hibernate配置文件 

MyBatis持久层用了163行Java代码，36行映射文件，19行MyBatis配置文件 

所以从编码的角度我比较推荐MyBatis，因为它将Java代码和Sql做了映射，编码非常清晰。当然对于复杂的sql，无论是Hibernate还是MyBatis，解决起来都够复杂的。 

 

2.增加数据 

Hibernate3增加1000条数据，平均每条耗时：27.6毫秒(具体数据：27000,26265,29609,27797,23938,30313,28375) 

MyBatis增加1000条数据，平均每条耗时：28.4毫秒(具体数据：29079,29359,31016,26375,26281,32475,24375) 

Hibernate3增加2000条数据，耗时61875毫秒，平均每条耗时30.9毫秒 

MyBatis增加2000条数据，耗时55515毫秒，平均每条耗时27.7毫秒 

Hibernate3增加5000条数据，耗时139500毫秒，平均每条耗时28.2毫秒 

MyBatis增加5000条数据，耗时127672毫秒，平均每条耗时25.5毫秒 

Hibernate3增加10000条数据，平均每条耗时28.1毫秒(具体数据：294922,274000,277109) 

MyBatis增加10000条数据，平均每条耗时26.9毫秒(具体数据：260343,272687,270031) 

综上： 

Hibernate3增加44000条数据，共用时：1240703，平均每条耗时：28.1 

MyBatis增加44000条数据，共用时：1185209，平均每条耗时：26.9 

抓图如下： 

 

 

 

3.删除数据 

Hibernate3在44000条数据中，随机删除一条数据，耗时：41毫秒 

MyBatis3在44000条数据中，随机删除一条数据，耗时：40.1毫秒 

抓图如下： 

 

 

 

4.修改数据 

也许是测试次数太少，在修改这方面，我认为数据还是存在一定偏差。 

Hibernate3随机修改一条数据，耗时：18.1毫秒 

MyBatis随较修改一条数据，耗时：3.2毫秒 

抓图如下： 

 

 

 

5.查询数据 

Hibernate3随机查询一条数据，耗时：12.2毫秒 

MyBatis随较查询一条数据，耗时：5.6毫秒 

抓图如下： 

 

 

 

6.删除所有数据 

Hibernate3删除45991条数据，耗时：812毫秒，平均每条56.6毫秒 

MyBatis删除46259条数据，耗时：906毫秒，平均每条51.0毫秒 

抓图如下： 

 

 

 

7.回收表空间 

Hibernate3回收表空间，耗时62毫秒 

MyBatis回收表空间，耗时62毫秒 

这里需要说一下的是，Hibernate3中不能利用映射删除表空间，只能直接执行sql，具体可以参考文章：http://javapub.iteye.com/blog/876147 

所以二者的回收方法都是同时执行sql，自然速度一致。 

抓图如下： 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

在向大家详细介绍Hibernate与ibatis的区别之前，首先让大家了解下Hibernate有着ibatis无法替代的优势，然后全面介绍Hibernate与ibatis的区别。

 

Hibernate在解决性能问题方面做得非常好。有了它的缓存机制，使用第三方缓存和数据库连接池，就较好的解决的性能问题。但这些还不够，Hibernate给了开发者足够的自由，让开发者自己去控制性能问题。

 

学习了一段时间的ibatis，我觉得Hibernate有着ibatis无法替代的优势。

 

1.Jboss，Hibernate是jboss的项目，jboss的所有项目的持久层都采用的Hibernate，要知道，jsr规范组的专家们大多数是来自jboss的，在一定程度上说，jboo引领着java的发展方向。使用Hibernate，跟着jboss，不偏离java的发展方向。

 

2.Gavin King，我最崇拜的偶像，他不仅发明了强大的Hibernate，还搞出了同样强大且优雅的web2.0应用程序框架seam.他是ejb3.0专家组成员之一，是jpa规范请求的领导者，他java领域最有发言权、最权威的领袖人物之一。现在，他领导web bean的，jsr299的发展，web bean规范的制定，全球软件巨头如ibm、oracle、bea和apache没有一个反对，纷纷响应。Web bean，想象起来，实在太美好了，完全的松耦合和强类型，所有的应用组件生活在一个应用组件上下文context中，相互合作。那时将不再有各种各样的上下文环境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有Hibernate的session，不再有持久化上下文，不再有事务上下文，不再有安全上下文，所有组件生活在一个大家庭中，大家其乐融融，实现天下的大和平。

 

3.osgi，我认为现在最值得学习的一个技术，有了osgi，实现真正的多模块开发，改变传统的开发方式。现在，已经有了Hibernate osgi，spring dynamic modul（osgi），struts 2 同样实现了对osgi的支持。目前，eclipse是基于osgi开发的，ibm的websphere v6.1，bea的所有产品都重构在osgi上，spring的应用服务器同样基于osgi，在EclipseCon2007上，osgi成为了主要的话题。Osgi受到如此的待遇，一点不奇怪，因为他具有无比强大的功能，改变传统的软件开发方式。Osgi采用树设计模式，将一个项目分成多个模块（bundle），每个模块单独部署，单独运行，说白了，就是将一个工程分成许多的插件，每个插件单独开发，重复使用，实现完全的即插即用。太令人激动了。如果公司的软件开发基于osgi，将会有大量的重复使用的osgi bundles，公司将会积累大量的无形资产，软件开发将会越来越快。而ibatis现在还没见到对osgi的支持。

 

4.Hibernate的社区非常繁荣，ibatis则相对平静。

 

综述，Hibernate还有很多优秀的特点，只是我们不知道。Hibernate与ibatis，就像大家闺秀对小家碧玉，大家闺秀不仅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有发展前途。小家碧玉尽管也很有魅力，但始终比上大家闺秀。

 

Hibernate所做的不仅仅是dao层的持久化工作，而ibatis恰恰如此。

 

选择Hibernate，选择orm的王者，选择更全面的工作体验，选择更高效的工作方式，选择更多的利润；选择Gavin King，跟着领袖走；选择jboss，追随开源的潮流，不偏离java的发展方向。

 

一切都不是借口。一切都在发展，Hibernate会越来越好。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.优点

 

　　简单：

 

　　易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

 

　　实用：

 

　　提供了数据映射功能，提供了对底层数据访问的封装（例如ado.net），提供了dao框架，可以使我们更容易的开发和配置我们的dal层。

 

　　灵活：

 

　　通过sql基本上可以实现我们不使用数据访问框架可以实现的所有功能，或许更多。

 

　　功能完整：

 

　　提供了连接管理，缓存支持，线程支持，（分布式）事物管理，通过配置作关系对象映射等数据访问层需要解决的问题。提供了dao支持，并在dao框架中封装了ado.net，Hibernate和datamapper.增强系统的可维护性：通过提供dal层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。

 

　　2.缺点

 

　　滞后性：

 

　　还没有明确对。net2.0的支持。最新版本在2.0下编译可以，但有些单元测试不能通过。

 

　　不成熟，工程实践较少：ibatisnet在实际项目中的使用较少。 只是理论上可行。

 

　　半orm，工具支持较少：需要我们自己写sql，并且。net下还未发现可以自动生成业务层类和配置文件的工具，这点和Hibernate不一样，Hibernate会为我们的数据库直接产生sql，并有一些辅助工具。因此使用ibatis比Hibernate要多做一些工作。

 

 

　　没有最好的框架，只有最适合的框架。存在的便是合理的，它存在就说明有它存在的道理。但它未必为我们存在。所以选择一个框架最主要的是看它对你有没有意义，意义有多大，是不是比其他框架带给你的好处要多。没有绝对的优点也没有绝对的缺点，重要的是看在什么情况下讨论。

 

　　上面说了部分的ibatis的优点和部分缺点。这些优点从理论上证明ibatis对任何数据持久层都合适，但未必是最好的选择。下面对上面的优缺点分别从两方面讨论。

 

　　简单：

 

　　我们都喜欢简单，简单意味着学习成本低，使用中出错的可能性低。同时，简单的东西一般来说功能不够强大。反过来，复杂的东西学习成本高，用起来不方便，并且团队没有很强的技术实力，一般不要使用。

 

　　实用：

 

　　解决了项目中需要解决的问题，这是任何实际工程中采用的框架和工具都应具有的性质，否则就不要拿到实际项目中来。

 

　　灵活：

 

　　灵活有两层意思，一种是简单