什么时候用hibernate,什么时候用Ibatis 什么样的项目用hibernate更合适? 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 看看夏昕的教程吧那里说了什么情况下用ibatis，而不用hibernate下载地址：http://java99.com/?m=ViewSoftware&id=48 Hibernate相比iBatis有1个优势：能跨数据库。前提是坚持用HQL而不是SQL。除此之外，看不到更多的优势，相反面向对象的设计方式跟关系式数据库很难吻合。虽然作者费尽心机，但是效果依然不够理想。相反为了达到一丁点目的，就把配置搞得生涩难懂。当系统（数据库操作部分）比较复杂，又有跨数据库的需求，那么可以考虑Hibernate除此之外，可能其他的ORM是更好的选择（不一定是ibatis） 这是从夏昕的<<iBATIS 2.0 开发指南>>抄来的=========================================相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半自动化”的ORM实现。所谓“半自动”，可能理解上有点生涩。纵观目前主流的ORM，无论Hibernate 还是Apache OJB，都对数据库结构提供了较为完整的封装，提供了从POJO 到数据库表的全套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate或者OJB 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握，Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执行。大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。在笔者的系统咨询工作过程中，常常遇到以下情况：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 的出现显得别具意义。 如果系统原有表结构设计太复杂或者原有sql庞大复杂 就选用ibatis比较好 可以直接将sql拿过来用 听说hibernate对系统性能会有些影响，ibatis有没有这个问题。 感觉还是ibatis用起来比较方便，hibernate全部封装了，用起来总是不爽 ibatis好象写配置文件也不比JDBC代码少啊，不知道大家有些什么工具来简化这种操作？ 最近刚好在研究ibatis，关注下。PS:用hibernate有些日子了，感觉性能上的确是不怎么地。呵呵！ hibernate的使用配置很复杂,上手慢,性能方面不如Ibatis,还它对sql语句强大不能充分发挥,Ibatis学习容易,是面向sql的配置文件,可以完成与通常sql语句的功能,配置简单,上手快,且性能很好,配置相当灵活.我想信你用了以后就会有所体会.呵呵,个人意见,仅供参考哦 感觉hibernate还要学hql语句，有点不爽。 J2ee Development without EJB 里讲持久化那一章有就这个问题进行讨论, 楼主可以去看看 abator可以自动生成ibatis的映射文件.http://www.abator.com/大家可以去看看使用起来很容易 ibatis 最大的优势之一就是可以用上SQL全部功能 用java怎样逐一获取一个目录及其所有及目录的txt文件的文件名 求教下为啥不能分页 怎样获取jsp页面的label标签 并为其赋值 怎么去掉项目加载spring之后出现的一堆这样的log? Java DB操作类的设计代码 EL表达式 sturts2 struts的页面为什么都是.do为后缀的呢？ mysql的小问题??? 请问,如何获得ejb3.0 webservice 的调用者的IP??谢谢 请教：权限的锁定控制问题 struts 的ActionErrors的classcastException问题 如何 将一些消息 写入XML文件中
http://java99.com/?m=ViewSoftware&id=48
除此之外，可能其他的ORM是更好的选择（不一定是ibatis）
=========================================
相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半
自动化”的ORM实现。
所谓“半自动”，可能理解上有点生涩。纵观目前主流的ORM，无论Hibernate 还是
Apache OJB，都对数据库结构提供了较为完整的封装，提供了从POJO 到数据库表的全
套映射机制。程序员往往只需定义好了POJO 到数据库表的映射关系，即可通过Hibernate
或者OJB 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握，
Hibernate/OJB 会根据制定的存储逻辑，自动生成对应的SQL 并调用JDBC 接口加以执
行。
大多数情况下（特别是对新项目，新系统的开发而言），这样的机制无往不利，大有一
统天下的势头。但是，在一些特定的环境下，这种一站式的解决方案却未必灵光。
在笔者的系统咨询工作过程中，常常遇到以下情况：
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 的出现显
得别具意义。
PS:用hibernate有些日子了，感觉性能上的确是不怎么地。呵呵！
Ibatis学习容易,是面向sql的配置文件,可以完成与通常sql语句的功能,配置简单,上手快,且性能很好,配置相当灵活.我想信你用了以后就会有所体会.呵呵,个人意见,仅供参考哦
http://www.abator.com/
大家可以去看看使用起来很容易