帮助IT团队快速构建符合jt808协议部标的基于java技术的GPS和视频平台(2379423771@qq.com)

Ibatis VS Hibernate

   近日,在JavaEye论坛中,看了Ibatis和Hibernate的帖子,看后,心里觉得的憋闷,不说不快, 这里,我想更细化一下:

    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的好,有谁真的是高手?

       我认识一个人,连Hibernate的命名查询、悲观锁、乐观锁之类的,都不清楚,还在那说:“说Hibernate不好的人,只是他不会用Hibernate,高手使用EJB也一样用的很顺溜“,我这辈子,最最讨厌的就的这样的人,人家明明用Spring很简单,很快乐,为什么要用EJB,充高手。换过来,项目使用Ibatis来做动态查询,很快的就解决问题了,为什么要去学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,不明白,他为什么说这样的话,这与新旧项目有什么区别? 新的项目就真的可以使用Hibernate吗。

 

 

  

 

 


 

posted on 2007-05-05 18:14 Speed 阅读(5389) 评论(19)  编辑  收藏 所属分类: 框架设计J2EEHibernate & Ibatis

评论

# re: 不做技术的奴隶 2007-05-05 22:05 Welkin Hu

(
最终的运用:

在基于Spring的容器事务管理之下,
增、删、改、存及在事务中的查询,使用Hibernate。
非事务性的查询及报表,都用Ibatis,维护非常的直观方便,开发速度上也快很多。
)

按楼主的这个做法,岂不是要同时掌握Hibernate和iBatis两门技术?同时为一个表写hibernate mapping和ibatis sql? 这本身已经有很大的重复量了呢。

  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 01:14 bigbigbig

兄弟说得相当精彩!!!!!!

尤其是第二条,我深有体会!!!!!!!!

支持!  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 09:19 山风小子

平衡唯美~  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 09:49 OneEyeWolf

@Welkin Hu
你可以不用ibatis,你可以用Hibernate来写SQL,这没有关系。

我喜欢和有实践的人争论。

  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 11:33 Welkin Hu

是啊,我们现在的做法就是在Hibernate中写HQL和SQL,没有用iBatis。不过楼主的最佳实践中讲到“非事务性的查询及报表,都用Ibatis”。我有些纳闷:在已经使用了Hibernate的前提下,直接在Hibernate中写SQL,和在iBatis配置SQL,哪个更好呢?  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 11:44 OneEyeWolf

两者结合,只是表明一种观点,技术是相宜互补的,用来解决问题的。

也是我的项目当中的实践,对于其它人和项目,是否适合,不得而知。

所以不能叫best practice.

我想,好处是自己动手实践而来,自己找一个例子,做一下,比如动态拼SQL,写一个Hibernate,再写一个ibatis,比较一下,就知道了。

空对空的讨论,只能激起矛盾,没有任何意义。

  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 14:46 leekiang

我认识的人里面压根就没有人懂悲观锁、乐观锁、事务、命名查询、缓存等,有人只会照着写select、insert、update、delete,还说他懂hibernate。我不知道这样做出来的项目能不能用。  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 18:29 yeshucheng

呵呵,很同意楼主的观点。
做了快5年的项目下来,真的是很有体会!
记得以前我和一个朋友讨论过:某些程度的东西不要一味的为了Hibernate而Hibernate,这个就是最可悲的事。在一个项目很紧张的时候,客户和老板容不得你去过去思考使用什么技术,他们的观点一直就是:我能看到你的实现就可以!
大家不要否认这个现状,这个也是中国目前的状况。有时候同事和我说:我能否使用JDBC完成这个(这个业务要使用到6张表)。我的态度是:完全可以。如果使用Hibernate去做,大家想象一下会怎么样。
  回复  更多评论   

# re: 不做技术的奴隶 2007-05-06 18:30 yeshucheng

不过我觉得在以前很多朋友使用过很多SQL写过很多报表的朋友,写JDBC或者IBatis这些东西来做完全得心应手!既然人家写这个能够体现一个同样的思想表达何必再去强求呢?呵呵
一般CRUD这些东西完全可以使用Hibernate去做。但是如果真的牵涉到很强硬的readonly的业务查询没有必要去专牛角尖,使用诸如JDBC或者IBatis完全可以,只要实现得体,完全没有问题!  回复  更多评论   

# re: 不做技术的奴隶 2007-05-07 09:38 Welkin Hu

没用过iBatis,所以不知道它对于动态SQL有多好。反正,基于不愿意为一个表做两套O/R Mapping和储备两种技术的目的,我没有在产品中引入iBatis。  回复  更多评论   

# re: 不做技术的奴隶[未登录] 2007-05-07 20:19 javacap

我干脆就两者都不用,自己简单封装一下(不要说什么重复发明轮子,每个人 都有 适合自己的项目的轮子).做得更漂亮。  回复  更多评论   

# re: 不做技术的奴隶 2007-05-08 09:29 Juliashine

我见过有的人,打着OO和扩展性的旗号,硬生生的把一个表,拆成了三个表,而这三个表,本来,只需要增加一个类型字段,再做一些冗余,就可以是一个表。现在查询时,还要把这三个表Union到一块来查。当需求变更时,增加一个字段,不仅要改变三个类,还要改变三个表,简直是乱伦。

-----------------------------------------------------------------

这一段怎么好像是说我们公司一样  回复  更多评论   

# re: 不做技术的奴隶 2007-05-14 08:59 Welkin Hu

@Juliashine
嘻嘻,不管什么O/R Mapping工具,好像都没有提倡OO式的表结构哟。O/R mapping这个名字中,R可是三分天下有其一的。如果真的想玩OO式的表,那就玩面向对象数据库得了。连O/R mapping都省了。
  回复  更多评论   

# re: Ibatis VS Hibernate 2008-07-17 08:54 lan

我不用Hibernate就是特烦某些人拿OO的思想往关系数据库上套,这种改变数据库中心思想的行为,实在是太...

我周围支持Hibernate的人大都是些新手,因为用这个可以省下很多思考,也就是偷懒,他们平常作的都是简单的CRUD,能写复杂SQL的几乎没有。

对于那些动辄就写数十行甚至上百行SQL的业务应用以及为了性能反复调优的人来说,和没有这种经历的人去讨论IBATIS和Hibernate就如同对牛弹琴。

我曾遇到这么一个人,先学一样东西时,有了解后就大呼不错,很好,很棒,有了它天下大可以去了,改天又学了一样,发现还要好,就觉得这才是闯天下的根本,以前的根本就是狗屎,改天又接触了一样技术,发现这才是潮流,那些东西根本就是老掉牙的东西...云云。你能如何的评价这样的人呢,你能说他不对吗?由于它的认识的局限性,而发出的言论,除了会心一笑,你还能做什么?  回复  更多评论   

# re: Ibatis VS Hibernate 2008-07-17 10:06 OneEyeWolf

@lan
right. 产生技术的争论,很头疼,有时候取决与谁的推动力大,而不是谁的正确,只有结果知道谁对谁错。  回复  更多评论   

# re: Ibatis VS Hibernate 2008-08-16 12:02 wueddie

于我心有戚戚焉!

类似楼主的想法和心情我两三年前也曾有过。虽然我无意于这种争论,但是非常同意楼主关于面向对象和数据库关系的见地。其实只要本着实事求是的精神,要得出类似的结论是不难的。但是实际情况却是很多人以偏盖全。尤其是在JEE领域,很多人对数据库的认识都有限。总以为面向对象是解决一切问题的法宝。  回复  更多评论   

# re: Ibatis VS Hibernate 2008-11-12 13:19 zhouzhao21@gmail.com

如果有时间,我觉得躺在草坪上看看Unix的编程艺术,看看代码大全,看看Oracle的编程艺术,比看Hibernate的SB书要惬意多了。

-----------
同感  回复  更多评论   

# re: Ibatis VS Hibernate[未登录] 2008-11-28 09:27 henry1451

LZ和大家的评论都说的非常中恳.  回复  更多评论   

# re: Ibatis VS Hibernate 2013-08-09 13:34 钻石风暴

完全不用hibernate,直接无视,曾经用过,什么垃圾玩意啊,一个简单问题搞那么复杂。简单查一个多表关联列表ibatis5分钟搞定,hibernate搞那么复杂。数据库的二维表和oo思想表面上看好像有点像,其实如果用的深入了,二者是根本无法调和统一的事物,因为关系数据库是着眼于关系,针对一个表来说每个字段归根到底是一对一关系,才形成了表。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

导航

留言簿(15)

随笔分类

值得一看的博客

积分与排名

最新评论

阅读排行榜