Hibernate VS iBATIS
转之ewolf的工作专栏
简介
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.实践是检验真理的唯一标准.鞋合不合适,只有试了才知道