本文对比了ibatis和hibernate两种ORM框架的特点，分析了它们在不同场景下的适用性，包括新项目开发、数据库二次开发及海量数据处理等场景。
ibatis与hibernate比较
摘录自：http://javapub.iteye.com/blog/751485
相对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开发的工作量和数据库移植性上的让步，为系统设计提供了更大的自由空间。
hibernate与ibatis的对比：
二次开发
当系统属于二次开发,无法对数据库结构做到控制和修改,那ibatis的灵活性将比hibernate更适合
海量数据
系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的sql语句（或存储过程）才能达到系统性能设计指标。在这种情况下ibatis会有更好的可控性和表现。
自动化程度
ibatis需要手写sql语句，也可以生成一部分，hibernate则基本上可以自动生成，偶尔会写一些hql。同样的需求,ibatis的工作量比 hibernate要大很多。类似的，如果涉及到数据库字段的修改，hibernate修改的地方很少，而ibatis要把那些sql mapping的地方一一修改。
与数据映射关系
ibatis以数据库字段一一对应映射得到的po和hibernte这种对象化映射得到的po是截然不同的，本质区别在于这种po是扁平化的，不像hibernate映射的po是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。
最关键的一句话是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
---------------------------------------------------------------------------------------------------------------------------------------
与mybatis的比较
摘录自 http://jc-dreaming.iteye.com/blog/1003778
在 Apache 寄居六年之后，iBatis 将代码托管到 Google Code。在声明中给出的主要理由是，和 Apache 相比，Google Code 更有利于开发者的协同工作，也更能适应快速发布。于此同时，iBatis 更名为 MyBatis。
Mybatis实现了接口绑定，使用更加方便
在ibatis2.x中我们需要在DAO的实现类中指定具体对应哪个xml映射文件，
而Mybatis实现了DAO接口与xml映射文件的绑定，自动为我们生成接口的具体实现，使用起来变得更加省事和方便。
这可以说是Mybatis最重要的改进。
注意：
虽然Mybatis支持在接口中直接使用annotation的配置方式来简化配置，
不过强烈建议仍然使用xml配置的方式。毕竟annotation的配置方式功能有限且代码入侵性太强。使用xml配置方式才能体现出Mybatis的优势所在
对象关系映射的改进，效率更高
相信很多在使用ibatis2.x的朋友并没有通过ibatis的xml映射文件来实现对象间的关系映射。其实也确实没有必要那么做，因为ibatis2.x采用的是“嵌套查询”的方式将对象之间的关系通过查询语句的直接拼装来实现，其效果和在DAO或Service中自行封装是一样的。
不过这种方式存在“N+1查询问题”。
概括地讲，N+1查询问题可以是这样引起的：
? 你执行了一个单独的SQL语句来获取结果列表（就是+1）。
? 对返回的每条记录，你执行了一个查询语句来为每个加载细节（就是N）。
这个问题会导致成百上千的SQL语句被执行。这通常不是期望的。
而在Mybatis中，除了兼容ibatis2.x中的“嵌套查询”方式外，还提供了直接“嵌套结果”的方式，其效果相当于直接通过一句sql将查询出的dto对象自动封装成所需的对象。
具体实现方法请自行参考Mybatis官方使用手册，不在此累述.
不过实际上这一改进所带来的好处也是很有限的。因为这一方式在使用分页的时候并不起作用，或者说嵌套对象的结果集是不允许进行分页的。这一点在Mybatis框架中已经做出了明确的限制（org.apache.ibatis.executor.resultset.NestedResultSetHandler里34行），而实际项目中需要分页的情况又特别多……
仔细一想，一对多映射确实不能通过配置文件来分页，因为这时查询出的记录数并不等于实际返回对象的size，不过一对一映射为什么也不允许就不太明白了。可能是因为一对一是一对多的特例，而在设计框架的时候并没有考虑去处理或是难于处理这一特例吧。
MyBatis采用功能强大的基于OGNL的表达式来消除其他元素
熟悉struts2的人应该对OGNL表达式不会感到陌生，
MyBatis采用OGNL表达式简化了配置文件的复杂性，使用起来更简洁。
扫一扫
1377
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
