分享

hibernate 与 ibatis

 昵称10504424 2013-08-26
库表关系的复杂度,首先取决于需求,不取决于设计,设计能力强的人,也要遵守库表设计的规范,从巴克斯三个范式上,原则上也要遵守。不能说用了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的好,有谁真的是高手?

     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,不明白,他为什么说这样的话,这与新旧项目有什么区别? 用不用Ibatis,我觉得对我上面说的几点有关。

 

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多