再论Hibernate和iBatis

 今天，用Hibernate做的一个系统，测试时出现Java heap space溢出的问题。

道理很简单，对象是个大对象，长度为256的字符字段若干，CLOB字段若干。生成列表时，Hibernate老实地将所有内容装入对象LIST，很快堆就爆了。

从Hibernate开发之初，就一直不很感冒，很喜欢iBatis。原因无它。

Hibernate并没有创造出新知识来，而是在SQL的基础上，生编出一套对象不对象，数据库不数据库的HQL来。

你说HQL适合OO，我很发笑，我看不出对象除了属性和方法之外还会有FROM WHERE。

好的框架是什么呢？Spring就是一例。配置完之后，只要使用标准的POJO编程方法，就能解决许多问题。

而Hibernate搞来搞去，我就没看过几个真正精通的。

 

有些技术，是永久的，不变的。例如：SQL，不论哪个平台，哪种语言，精通SQL是没有坏处的。

而现在的问题是，许多Java程序员在使用Hibernate之后，把不变的核心的东西忘记了。连基本的SQL都忘记了。

 

相比之下，iBATIS既能将对象与数据库映射，又不需要学习生编硬造的HQL，既能让你继续享受你现有的SQL资产，还会不断深化你的SQL技能。

 

不论技术如何变，底层的东西并没有很大的变化。用优雅的方式，缓解现有的负担，而不增加新的负担，才是好东西。试图造出银弹推翻一切现有知识，实际是不成熟的表现。

 

以Hibernate的Oralce CLOB处理为例，由于Oracle驱动的问题，Hibernate默认的处理方式根本不生效。于是要特殊处理。

特殊处理之后，转移到SQL或MySQL上，还是要处理。

 

有人说，使用iBatis，缺乏移植性。

实际上，标准的SQL，可移植性也相当好。

另外，只谈数据库的移动性是没意义的。如果我换一个开发语言呢？iBatis的SQL资产我还是可以继续使用的，而Hibernate的HQL资产如何利用呢？