首先这个题目有点哗众取宠,呵呵,故意的.
参考了网上许多前辈的见解,然后加了自己一点点的理解.如果有什么板砖,欢迎来拍 chinaewolf@gmail.com
简介
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.实践是检验真理的唯一标准.鞋合不合适,只有试了才知道
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yan_auvtech/archive/2009/12/30/5104050.aspx
