Hibernate & Ibatis

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吗。