反思Hibernate，可以有更简洁、更高效的ORM实现

　　我思考了良久才决定发这篇文章，各位老大手下留情。

　　假设有一张表Student,有几个字段ID,Name,Gender,BirthDay，实际上这么一个从数据库设计中直接生成的类就可以很好地满足我们对于ORM的要求：

public class StudentSchema extends Schema {
	private int ID;

	private String Name;

	private String Gender;

	private Date BirthDay;

	public static final TableName = "Student";

	public static final PrimaryKeys PKs = new PrimaryKeys(new String[] { "ID" });

	public Date getBirthDay() {
		return BirthDay;
	}

	public void setBirthDay(Date birthDay) {
		BirthDay = birthDay;
	}

	public String getGender() {
		return Gender;
	}

	public void setGender(String gender) {
		Gender = gender;
	}

	public int getID() {
		return ID;
	}

	public void setID(int id) {
		ID = id;
	}

	public String getName() {
		return Name;
	}

	public void setName(String name) {
		Name = name;
	}
}

　　其中Schema是一个公用类，里面主要是提供了fill()，update(),delete()，backup()等功能。其中fill()就是通过主键返回一条记录，其他几个方法就不用说了吧。

　　但反观Hibernate呢？我们需要一个与StudentSchema类似的POJO类，一个DAO类，一个*.hbm.xml映射文件，才能达到类似的效果，机制繁琐，性能消耗明显要高。

　　我不知道为什么这么简单的高下立见的对比没有引起大家的注意，我也承认我对Hibernate浅尝辄止，并且我估计会引来大片的攻击，但我确实想像不出Hibernate有可能会比这更简洁更高效。在我们的实际应用中，StudentSchema是由工具从PowerDesigner中直接生成的，开发人员根本不管ORM，直接使用即可。StudentSchema是硬编码的类，不需要进行字节码动态生成，不需反射，不需配置文件，十分简单。

　　更重要的是，我们这个ORM实现总共才几千行代码。Hibernate功能很多，但我们的ORM实现虽然代码很少，但己能覆盖实际开发中的全部ORM需求。我将以回复的方式加以说明。

评论

91 楼 flyzht 2009-06-10  

hibernate和所有ORM都是为了解决OR映射而产生的，如果面向数据库的话就用JDBC或JDBCTEMPLATE好了

90 楼 icewubin 2009-06-10  

flyzht 写道

说到底关键是思维问题，如果是按照领域建模的思维来进行开发，就会有很多模型互相关联依赖来完成领域逻辑，那么会觉得HIBERNATE很方便，如果是围绕数据库建模，MODEL只是一个数据容器的话，当然会觉得HIBERNATE很麻烦，HIBERNATE效率低是由于OR不匹配造成的，可以通过良好建模减少模型关联来提高效率

你这个效率低说的太笼统，就是这种类似的不明白的说法，让很多人以为Hibernate效率低。

说到底就是ORM使用不当，或者说数据抓取策略的使用不当，导致了很多无效的sql的执行。

还有，再强调一点，hibernate不仅仅只能用于自上而下的建模，自下而上一样是很好用的，当然没有任何教材会从头到尾的讲自下而上的全套技巧，但是不等于不能做，而且也能做得很好。

89 楼 flyzht 2009-06-10  

说到底关键是思维问题，如果是按照领域建模的思维来进行开发，就会有很多模型互相关联依赖来完成领域逻辑，那么会觉得HIBERNATE很方便，如果是围绕数据库建模，MODEL只是一个数据容器的话，当然会觉得HIBERNATE很麻烦，HIBERNATE效率低是由于OR不匹配造成的，可以通过良好建模减少模型关联来提高效率

88 楼 zypro 2009-06-10  

wyuch 写道

我不知道ORM概念始于何时，在你99年使用ORM三年后，微软发布.NET 1.0中没有这样技术门槛低的东西，1.1继续没有，2.0依然没有，以至于你所说的SPL之类的东西出现；同样在你使用JDK1.2之后的长达N年之后ORM都没有纳入J2EE的范畴，直到Hibernate等ORM实现己成气侯，才有JPA出现。所以你的所谓“实在是比较可笑”是不是先去笑J2EE或者.NET比较好？

我觉得可笑的是,在2009年6月份,有人把JDBC稍微封装一下,当成是新鲜事物来说. 美名其曰:"效率高","可以解决所有数据库开发中的问题".

wyuch 写道

有哪些是我的框架不能解决的？级联？导航？继承？对象一致性？可重复读？不能并发？因为就实际应用而言，还没有遇到不能处理的数据库开发的问题。

我明天去把汇编包装一下,写一篇文章:反思Java,可以更简洁,更高效的编程. 
节选如下:
我的方案代码简洁(无需申明任何类和方法,只需玩玩寄存器), 运行速度快(没有GC,没有间接内存分配,连虚拟机都不用,谁敢跟我比?),而且可以解决所有编程问题,多线程,网络,OO......(有什么是汇编干不了的吗?)

wyuch 写道

我的ORM框架要写的代码比Hibernate少，并且效率高，学习曲线短，我想这应该是没有太多疑问的。Hibernate功能强，但又有配制又有反射又有动态字节码，所以效率比我的差，我想这也是没有疑问的。

不懂Hibernate,就出来"反思"...
常识性的问题,封装层次高的,通常都会带来更简洁的代码.
之所以你觉得你的代码少了,两个原因,第一,你觉得用模板生成的代码不算代码. Hibernate的配置文件也可以用模板生成,或者使用Annotation几乎不用配置.所以实现那些你所谓的ORM,代码一定比你少. 第二,你的应用entity只和数据库打交道,保存一下只需一个save,所以你觉得代码少. 殊不知在业务层,如果domain设计的好,是可以用最简洁最OO的代码体现所有业务逻辑,Hibernate接管了所有持久化的操作,几乎都不用去显式调用数据读写的逻辑,你怎么可能做到更少的代码?
至于效率问题,讨论的够多了. 配置和反射,包括动态字节码,从来就不是一个应用的效率瓶颈. 没有听说过哪个数据库为中心的应用,是因为反射而影响了效率. 填写entity所花的时间,都比这个长......
Hibernate提供了orm级别的缓存,还有众多优化的手段. 请问你的orm能提供什么样的优化? 借助第三方的cache机制,得到的性能提升也算是你的框架的优势,实在是没话说... 小弟不才,要把第三方缓存用对,用好,自认不是那么容易... 当然,这个不是你框架的范畴,不会对你的"学习曲线低"这个优点构成影响.

87 楼 icewubin 2009-06-10  

wyuch 写道

是的，你说的都对，但我不用这些机制，而且不需要解析HQL，直接封装的JDBC，就算比Hibernate好得有限，也还是要好些的。另一个方面有点优势的是性能出现问题的话，我不需要怀疑我的ORM，他就这么简单，本身不构成性能问题，完全出自自己的团队，很好掌握，这算是自主开发的一点额外好处吧。

1.你说这些话的前提就是认为Hibernate有性能问题，有么？你听到的性能问题都是ORM使用不当导致的，例如N+1查询问题。这个问题分两个方面说，一方面Hibernate可以弃用大多数高级特性，只用少数功能，那就和你的框架接近了，另一方面无论哪种DAO（ORM或者自己封装），使用不当都会导致N+1的这类问题，这和框架本身无关，不是框架的性能问题，而是框架的使用问题。

2.自主开发当然有好处也有坏处，问题在于你说的相对于Hibernate的好处本来就不存在，你说的那些问题hibernate本身是没有的，最多平手而已。我再多说一个学习成本的问题，只要限定Hibernate高级特性的使用范围，再给几个例子，hibernate的培训也是很简单的，所以你说的学习成本也是没有可比性的，因为hibernate本身是足够灵活的，既可以面向OO编程，也可以面向SQL编程，如果只使用部分功能，何必去学那些整本书的hibernate教程呢。还有HQL的问题，hibernate可以不依赖于hql，之前说过了，面向对象的查询方式QDC、QBDC，基于Example的快捷查询QBE也很方便的。楼主还是多了解一下hibernate再来发表见解比较好。

3.至于代码生成还是自上而下或者自下而上，和hibernate本身没有直接关系，属于第三方代码生成工具而已。我提这个，原本是想楼主了解一下领域驱动设计的概念，再回过头来想ORM的作用。

86 楼 wyuch 2009-06-10  

icewubin 写道

wyuch 写道

Hibernate功能强，但又有配制又有反射又有动态字节码，所以效率比我的差，我想这也是没有疑问的。

这当然有疑问，有点想当然了吧。

配制只加载一次就会缓存，又不会每次读取配置文件，动态字节码也只生成一次class，也不会每次调用都生成一遍class，至于反射的性能问题，从JDK 1.4以后发射的性能就有大幅提高了。

是的，你说的都对，但我不用这些机制，而且不需要解析HQL，直接封装的JDBC，就算比Hibernate好得有限，也还是要好些的。另一个方面有点优势的是性能出现问题的话，我不需要怀疑我的ORM，他就这么简单，本身不构成性能问题，完全出自自己的团队，很好掌握，这算是自主开发的一点额外好处吧。

你前面的几个回复提到了代码简洁的问题，那种做法我确实是不知道的。我目前的做法是从PowerDesigner的概念设计或物理设计中直接生成硬编码的Schema类，不需要自己注解，直接使用Schema完成业务逻辑即可。当然Hibernate也可以从PowerDesigner生成DAO和POJO，做到一模一样的效果,所以也谈不上优势，但也没有劣势。

这种做法有个小小的好处就是可以从数据库设计中直接带来字段的中文名、字段注释之类的信息，在Eclipse等工具中能够直接有提示，在字段多的时候还是有些用处：

	/**
	* 获取字段Mobile的值，该字段的<br>
	* 字段名称 :手机<br>
	* 数据类型 :varchar(50)<br>
	* 是否主键 :false<br>
	* 是否必填 :false<br>
	*/
	public String getMobile() {
		return Mobile;
	}

	/**
	* 获取字段ProxyFlag的值，该字段的<br>
	* 字段名称 :是否使用Http代理<br>
	* 数据类型 :varchar(2)<br>
	* 是否主键 :false<br>
	* 是否必填 :false<br>
	* 备注信息 :<br>
	0-不使用<br>
	1-自定义配置<br>
	2-全局代理<br>
	*/
	public String getProxyFlag() {
		return ProxyFlag;
	}

85 楼 icewubin 2009-06-10  

wyuch 写道

Hibernate功能强，但又有配制又有反射又有动态字节码，所以效率比我的差，我想这也是没有疑问的。

这当然有疑问，有点想当然了吧。

配制只加载一次就会缓存，又不会每次读取配置文件，动态字节码也只生成一次class，也不会每次调用都生成一遍class，至于反射的性能问题，从JDK 1.4以后发射的性能就有大幅提高了。

即使考虑上其他因素（hibernate支持的功能多），hibernate真的比你的慢，能慢多少？主要性能瓶颈难道不是在SQL的执行上么？

84 楼 wyuch 2009-06-09  

zypro 写道

lz很愤怒,看得出来,尽管开头很谦虚的认为拍砖在所难免, 但其实对于这么个"比Hibernate跟简洁,更高效"的"orm"还是充满了自豪.

提到了所谓的一半以上的保险公司的核心业务,还有奥运会志愿项目. 其实不能代表什么问题. jdbc也承载了很多大型的项目,技术的初期,都是用简单的想法构成的.

你所怀疑的,10年就有很完善的东西. 其实根本无需怀疑. java从96年开始红火,99年已经开始做成熟的商业运用了.任何一个稍具规模的公司,在运用jdbc频繁存取数据的时候,都会想到实现一个基本的orm. 在用hibernate之前,我用的就是一个99年完成的orm,实现了sql生成,entity的填充. entity和基本crud的代码都是从excel的宏生成的. 这个没有什么值得骄傲的,技术门槛很低. 也就是为一些不想用EJB的应用而生的.

所以事隔多年,把这么个东西拿出来,还以为是什么新鲜事物,还号称 "有哪些是我的框架不能解决的？级联？导航？继承？对象一致性？可重复读？不能并发？因为就实际应用而言，还没有遇到不能处理的数据库开发的问题。 "   实在是比较可笑. 你之所以没有这些问题,是因为你的框架根本不包含这些解决方案,你的处理方式就是JDBC的处理方式,当然,你号称的效率,也是因为根本不考虑级联导航,不使用反射...你当然能够处理所有的数据库问题,因为JDBC可以嘛...

当然拍砖归拍砖,还是要赞赏一下lz的精神. 能把idea拿出来共享是很好的,如果能开源,还是能让很多人受益的. 只是既然是讨论,就要能接受不同的意见, 用了太多反问句,只会让人觉得,你只是想来听赞扬的... 似乎心胸略嫌不够开阔

99年JDK刚到1.2版本，你已经开始用Java做成熟的商业应用了，特别是还用到了你说的ORM，虽然你觉得没有什么值得骄傲的，我还是要表示深深的敬意和钦佩，恕我见少识浅，你是我目前见过的最高的高人。

当然这并不意味着我认同你的观点。

我不知道ORM概念始于何时，在你99年使用ORM三年后，微软发布.NET 1.0中没有这样技术门槛低的东西，1.1继续没有，2.0依然没有，以至于你所说的SPL之类的东西出现；同样在你使用JDK1.2之后的长达N年之后ORM都没有纳入J2EE的范畴，直到Hibernate等ORM实现己成气侯，才有JPA出现。所以你的所谓“实在是比较可笑”是不是先去笑J2EE或者.NET比较好？

我的ORM框架要写的代码比Hibernate少，并且效率高，学习曲线短，我想这应该是没有太多疑问的。Hibernate功能强，但又有配制又有反射又有动态字节码，所以效率比我的差，我想这也是没有疑问的。Hibernate功能强大，有高级特性，是我的ORM不具备的，但我的ORM如你所说“你当然能够处理所有的数据库问题”。以上还不够吗？99年就有的东西也好，技术门槛如何之低也好，只是对JDBC的简单封装也好，好用易用，是Hibernate这样的复杂方案之外的简装方案，它的意义不已经很明显了吗？何至于就这么夸张，就不能拿来和Hibernate比，何至于就如此“可笑”、“不自量力”、“达不到层次”呀。

我相信你很资深，但我对你讨论问题的方式不习惯。你没有真正比较过SPL和我的实现，就轻易地下“远远超过了lz的这个框架”的结论，你的一些用词如“不自量力”、“可笑”有些夸张，而且你神仙般地认为我“很愤怒”也让我无语。我并不想假装心胸多么宽阔，也确实对这个ORM多少有些自豪，但在一个技术问题的讨论中带上人品道德方面的评说，似乎也有点那么自以为是。

83 楼 zypro 2009-06-09  

lz很愤怒,看得出来,尽管开头很谦虚的认为拍砖在所难免, 但其实对于这么个"比Hibernate跟简洁,更高效"的"orm"还是充满了自豪.

提到了所谓的一半以上的保险公司的核心业务,还有奥运会志愿项目. 其实不能代表什么问题. jdbc也承载了很多大型的项目,技术的初期,都是用简单的想法构成的.

你所怀疑的,10年就有很完善的东西. 其实根本无需怀疑. java从96年开始红火,99年已经开始做成熟的商业运用了.任何一个稍具规模的公司,在运用jdbc频繁存取数据的时候,都会想到实现一个基本的orm. 在用hibernate之前,我用的就是一个99年完成的orm,实现了sql生成,entity的填充. entity和基本crud的代码都是从excel的宏生成的. 这个没有什么值得骄傲的,技术门槛很低. 也就是为一些不想用EJB的应用而生的.

所以事隔多年,把这么个东西拿出来,还以为是什么新鲜事物,还号称 "有哪些是我的框架不能解决的？级联？导航？继承？对象一致性？可重复读？不能并发？因为就实际应用而言，还没有遇到不能处理的数据库开发的问题。 "   实在是比较可笑. 你之所以没有这些问题,是因为你的框架根本不包含这些解决方案,你的处理方式就是JDBC的处理方式,当然,你号称的效率,也是因为根本不考虑级联导航,不使用反射...你当然能够处理所有的数据库问题,因为JDBC可以嘛...

当然拍砖归拍砖,还是要赞赏一下lz的精神. 能把idea拿出来共享是很好的,如果能开源,还是能让很多人受益的. 只是既然是讨论,就要能接受不同的意见, 用了太多反问句,只会让人觉得,你只是想来听赞扬的... 似乎心胸略嫌不够开阔

82 楼 icewubin 2009-06-09  

还有个问题，楼主默认就是采用了“表模式”，自下向上建模。

而Hibernate既可以自下向上，也可以自上而下（先领域建模，然后生成建表语句）。

楼主有空看一下Domain-Driven Design吧。

81 楼 icewubin 2009-06-09  

Hibernate除了强大的HQL，还有QBC、QBDC、QBE等OO的查询方式。

80 楼 icewubin 2009-06-09  

zypro 写道

但反观Hibernate呢？我们需要一个与StudentSchema类似的POJO类，一个DAO类，一个*.hbm.xml映射文件，才能达到类似的效果，机制繁琐，性能消耗明显要高。

1.现在都单DAO设计了，怎么会多一个DAO呢？就算是多一个专用DAO，继承一下，不用写任何代码，一个空DAO而已。

2.看来楼主没见识过精炼的Hibernate3的注解写法吧，工作量甚至于比你现在这种写法还要省事。

@Entity
public class Student {   
    @Id
    @AccessType(value = "property")
    private int ID;   
  
    private String Name;   
  
    private String Gender;   
  
    private Date BirthDay;   
  
} 

这里的AccessType大家注意一下，如果有不是默认的映射，需要自己写的话，有这句（整个class有这一句就行了），就能直接把配置写在属性上，而不用写在get方法上了。可能有人会问不加也没问题啊，不加的话，直接写，Hibernate会认为是采用field方式直接读写属性，不通过get和set方法，会引发很多其它问题。

楼主可以看看Hibernate源代码中的org.hibernate.cfg.ImprovedNamingStrategy。


3.机制繁琐么？性能消耗高么？理由呢？

79 楼 dellsoft 2009-06-09  

这里提到的功能，基本上在grails里面的都实现了。叫GORM，而且也很强大！

78 楼 mikeandmore 2009-06-09  

最简单的当然是JDBC的做法了。。。
没看出来你这个和JDBC的做法有什么不同。。。

封装的很没有意义。

77 楼 wyuch 2009-06-09  

zypro 写道

lz介绍个框架没问题. 问题在于方式不对.

首先,拿Hibernate做比较不妥当.

当我们使用Hibernate,确实觉得要花很多时间去熟悉各种配置和规则,包括最佳实践,都需要用一整本书来描述. 但是越深入越会惊叹于Hibernate对于ORM支持的完善. 除了实现了完整的关系,还包括了并发控制,类型转换等高级特性.用Hibernate做项目,几乎所有数据库开发中会遇到的问题,它都给出了可行的方案,可以使OO不受到范式不匹配的影响.这个是Hibernate这些年发展的方向,也是其复杂的原因. 觉得Hibernate没必要,只是因为应用的架构还没有到这个层次. 拿Hibernate来做比较,有点自不量力,更不用谈是什么"反思"了.

其次,不客气的讲,LZ的工具,还处于一个很原始的阶段. 大凡做数据库相关的项目, 都会实现一个类似的框架,来实现基本的sql生成,以及entity的填充. 除了这个两个功能,我没有看到lz的框架中还有什么别的东西. 类似的东西,10年前就很完善了. 我前面的回复里建议lz去看一下.net下的spl,是我用过的类似工具里做的最好的.是国人做的,尽管3年前就停止更新了,但是完善程度远远超过lz的这个框架,对于复杂的查询,都可以用Criteria来生成. 之所以Java世界里面没有什么类似的框架很出名,只是因为太简单,而且有了Hibernate和ibatis,不再有必要重复造轮子. 嫌Hibernate复杂的,只需要基本entity映射的,用ibatis,学习曲线也很短. 而且是经过多年发展的,稳定性和功能都很不错, 对于一些常见的问题,比如不同数据库支持,数据库的关键字冲突,大小写转换等,都有了考虑.

看这个帖子讨论的人很多,所以还是要泼点冷水.
此帖确实有点标题党. 建议只作为一个简单框架介绍,不要扯上Hibernate比较好.

我总结一下你的话：LZ介绍框架的方式不对，一不能拿Hibernate作比较，二是框架比较原始。

首先我感谢你的批评，感谢你介绍了一些东西。但这两点我都不能认同，而且第二点与介绍问题的方式有什么关系？

我希望你是看过我的回帖之后作出“应用的架构还没有到这个层次”之类的判断。我举过我们的产品在线演示的例子，举过国内一半以上保险公司核心业务系统的例子，我们的框架本身还做过奥运志愿者的项目，应该说这些系统（有些是巨系统）都运行得很好，我无从判断你的层次，但我愿意相信你的层次非常高，我想表达的意思是：如果没到那个层次并不影响软件本身，层次的意义何在？

我最想问的是数据库开发中会遇到的问题，有哪些是我的框架不能解决的？级联？导航？继承？对象一致性？可重复读？不能并发？因为就实际应用而言，还没有遇到不能处理的数据库开发的问题。

再说不能与Hibernate相比的问题，依我对讨论的情况的观察，我个人认为大部分人觉得这种比较是可以的。一种不同的解决问题的思路,本身就有比较的意义，一定要强弱相当功能相当才能比较吗？依你的标准，天下间不自量力的比较太多，谈不上反思的反思也太多了，多我一个又何妨。

在你的介绍之下，我看了SPL，“完善程度远远超过lz的这个框架”，我是不能认同的。再重复一下我说了很多遍的我的框架的优点：没有其他类，没有配置，不言自明。应该说仅就代码部分，我的框架与SPL有八分像，但在SPL中还是有XML配置，还做不到不言自明，还没有实现不同数据库之间基本兼容，例如分页查询（仅实现了一个SQLServer和Access下的TOP功能）。

引用

其次,不客气的讲,LZ的工具,还处于一个很原始的阶段. 大凡做数据库相关的项目, 都会实现一个类似的框架,来实现基本的sql生成,以及entity的填充. 除了这个两个功能,我没有看到lz的框架中还有什么别的东西. 类似的东西,10年前就很完善了.

有事务支持呀，有参数化的QueryBuidler处理复杂查询呀，有随机存取的DataTable呀，有日常操作常用的数据库操作的封装呀，更简洁的操作，更高的效率。而且我也一再承认过，我不是想做一个比Hibernate更强的东西，我只想要一个更简洁更高效的东西。“类似的东西,10年前就很完善了”让我很无语，你真的确定1999年的时候就有很完善的类似的东西了？要不请举个例子？

76 楼 yulenice 2009-06-09  

楼主...你不要在意太多..大家所说的出发点都是你想要的..也是你发帖的目的..在不足中前进.指出你的不足..我觉得应该感谢大家.虽然有些言词可能有点over,呵呵
我觉得够用就好,不管是不是标题党,不过很欣赏为这个行业做贡献的态度,而没有只停留在嘴边.

75 楼 zypro 2009-06-09  

lz介绍个框架没问题. 问题在于方式不对.

首先,拿Hibernate做比较不妥当.

当我们使用Hibernate,确实觉得要花很多时间去熟悉各种配置和规则,包括最佳实践,都需要用一整本书来描述. 但是越深入越会惊叹于Hibernate对于ORM支持的完善. 除了实现了完整的关系,还包括了并发控制,类型转换等高级特性.用Hibernate做项目,几乎所有数据库开发中会遇到的问题,它都给出了可行的方案,可以使OO不受到范式不匹配的影响.这个是Hibernate这些年发展的方向,也是其复杂的原因. 觉得Hibernate没必要,只是因为应用的架构还没有到这个层次. 拿Hibernate来做比较,有点自不量力,更不用谈是什么"反思"了.

其次,不客气的讲,LZ的工具,还处于一个很原始的阶段. 大凡做数据库相关的项目, 都会实现一个类似的框架,来实现基本的sql生成,以及entity的填充. 除了这个两个功能,我没有看到lz的框架中还有什么别的东西. 类似的东西,10年前就很完善了. 我前面的回复里建议lz去看一下.net下的spl,是我用过的类似工具里做的最好的.是国人做的,尽管3年前就停止更新了,但是完善程度远远超过lz的这个框架,对于复杂的查询,都可以用Criteria来生成. 之所以Java世界里面没有什么类似的框架很出名,只是因为太简单,而且有了Hibernate和ibatis,不再有必要重复造轮子. 嫌Hibernate复杂的,只需要基本entity映射的,用ibatis,学习曲线也很短. 而且是经过多年发展的,稳定性和功能都很不错, 对于一些常见的问题,比如不同数据库支持,数据库的关键字冲突,大小写转换等,都有了考虑.

看这个帖子讨论的人很多,所以还是要泼点冷水.
此帖确实有点标题党. 建议只作为一个简单框架介绍,不要扯上Hibernate比较好.

74 楼 pollyduan 2009-06-08  

诚如lz所言，Hibernate有很多功能，一般应用用不到，或无所谓。H看似有的地方不和章法，只能说一般人用不到，考虑不到，研究不到而已。
对于一般程序原来说，够用就可以了，无所谓对错。

73 楼 wyuch 2009-06-08  

只是我这个实现也比较笨，谈不上高效。

72 楼 wyuch 2009-06-08  

maoxiaolu2000 写道

楼主这个不知对于where部分的封装是怎么样
能否给讲解一下
对于参数的类型如何做比较高效的判断

public QueryBuilder(String sql,Object...obj)

QueryBuilder只是一个参数化SQL中参数的容器，提供了几个重载的构造函数和add()，以便容纳不同类型的的参数。所有的基本类型都会转成相应的对象。

执行时的类型:

//stmt为PreparedStatement，qb为QueryBuilder
ArrayList list = qb.getParams();
for (int i = 1; i <= list.size(); i++) {
	Object o = list.get(i - 1);
	if (o == null) {
		stmt.setNull(i, java.sql.Types.VARCHAR);
	} else if (o instanceof Byte) {
		stmt.setByte(i, ((Byte) o).byteValue());
	} else if (o instanceof Short) {
		stmt.setShort(i, ((Short) o).shortValue());
	} else if (o instanceof Integer) {
		stmt.setInt(i, ((Integer) o).intValue());
	} else if (o instanceof Long) {
		stmt.setLong(i, ((Long) o).longValue());
	} else if (o instanceof Float) {
		stmt.setFloat(i, ((Float) o).floatValue());
	} else if (o instanceof Double) {
		stmt.setDouble(i, ((Double) o).doubleValue());
	} else if (o instanceof Date) {
		stmt.setTimestamp(i, new java.sql.Timestamp(((java.util.Date) o).getTime()));
	} else if (o instanceof String) {
		stmt.setString(i, (String) o);
	} else {
		stmt.setObject(i, o);
	}
}