"HQL是object-oriented query language. Query是针对Domain object model的. 与你的relational model in DB毫无关系.
另外, 数据库的形式有许多种, relational, object-oriented, XML-native,berkeley database. 没有必要局限自己在relational db的框架之中."

Hibernate是ORM，跟“数据库的形式有许多种”中其他形式的数据库没啥关系吧。

HQL名义上是面对对象，实际使用中感觉就是把数据库里面的列名换成了对象的property名，其他在概念上有什么区别吗？

使用DAO layer的目的是要分离出Data Access Code, 建立的Domain Object Model与database的类型没有关系. 对于你的Business Tier和Presentation Tier, database的类型是完全屏蔽的.

Domain object model in Java program与Relational model in DB可以相差很大. 你对于O/R Mapping的理解还有待提高.

"使用DAO layer的目的是要分离出Data Access Code, 建立的Domain Object Model与database的类型没有关系. 对于你的Business Tier和Presentation Tier, database的类型是完全屏蔽的.

Domain object model in Java program与Relational model in DB可以相差很大. 你对于O/R Mapping的理解还有待提高. "

像其他很多模式一样，DAO也面临很多争议，到今天也非业界公认的best practice.

O/R Mapping及其代表hibernate更不一定非要和DAO扯上关系。使用O/R Mapping完全可以不使用DAO模式。

O/R Mapping本身就是为了弥补OO和RDB之间的语义差距，做到数据库层对OO层业务逻辑的屏蔽。最理想的O/R Mapping应该是在RDB上，对OO各种方法论完全没有影响。显然，很遗憾，Hibernate没能做到这一点。

大家一起提高吧。

HSQL其实应该是内存数据库HSQLDB的一个部分.其实hibernate 的tale关系和过滤等操作都是经过内存来匹配的(JVM中)，不符合宏观的三层架构体系。

joined sub class似乎可以实现，不过也不是很优雅就是了

实在看不懂你们是如何理解hibernate的，根本是在瞎评论！

连DAO模式,HQL的作用还没了解清楚就大谈持久策略!

这一贴我决定不评论什么了

像其他很多模式一样，DAO也面临很多争议，到今天也非业界公认的best practice.

O/R Mapping及其代表hibernate更不一定非要和DAO扯上关系。使用O/R Mapping完全可以不使用DAO模式。

O/R Mapping本身就是为了弥补OO和RDB之间的语义差距，做到数据库层对OO层业务逻辑的屏蔽。最理想的O/R Mapping应该是在RDB上，对OO各种方法论完全没有影响。显然，很遗憾，Hibernate没能做到这一点。

================================================================

这3条评论最肤浅！
1：请这位写一个非DAO模式的J2EE应用出来给我看看，不要光说不练！拿一些大词来吓人，大家都是搞技术的，没这个必要！DAO模式是在ORM之前就已经很成熟的持久层模式，不过ORM普及后DAO模式有了很多变种，但是围绕核心还是一种剥离业务的数据访问策略，而并非一种设计模式。这位居然大谈DAO不是最佳实践让我很纳闷。

2：不用DAO如何访问持久层，早期的Facade,SessionFacade就是现在的DAO前生，如果有异议，请你给出一个例子我看！DAO者 DATA ACCESS OBJECT也，是对象，不是模式。

3：只有第1句话是一句比较好的评论，后面的全是狗屁！把OR做到RDM是不是非OO语言还不能使用这种RDM了！我要跑个JCA Services还要跑N种RDM RAI了！简直瞎说

其它你们讨论的都比较极端.
我个人认为什么时用hibernate什么时用jdbc-sql完全是要根据你的系统需求.假如你的系统只是一些数据收集和数据处理的系统，那就用jdbc-sql好了，因为利用数据库的一些优秀的性能能提高你系统的性能.Rod johnason（Spring创建者）曾经也是这样强调.不能过于偏执.如果你系统中有大量的和领域相关的需求的话.那肯定要用hibernate去解决执久层的一些事务.除非你的业务实现不是基于OO的，如果采用面向对象去建立领域相关模型.那持久去最好使用hibernate这样的框架，这样可以避免自己再开发这个底层框架.这在java中是很好的选择.如果你搞过C就会知道，他们没有选择.因为持久层框架在.net中很少有.Microsoft公司一向是力推系统是以数据库驱动开发系统.这是因为他们有私心.他们想推销他们的数据库.所以有一些朋友从.net转到java的朋友很难转变.因为他们在.net中开发的系统都是非OO的.所以转过来总是不顺.

恩恩，同意cnbond的观点，不是所有java项目都必须或都适合使用hibernate的，这不是说hibernate本身不好，什么事情都没有绝对的(这是真理哦)。

如果你水平很高的话，你就会觉得他不会影响你的设计思路--前提是你的水平要很高。
替某些高手们回答你。

可以用NullSafeGet方法？

有一个词叫习惯，思维方法也是习惯。
有一个词叫绝对，OO不是一种绝对...

drinkjava

如果你水平很高的话，你就会觉得他不会影响你的设计思路--前提是你的水平要很高。
替某些高手们回答你。

無知的人，啥是水平很高？不能理解，hibernate還是不錯的，但要看怎樣用了，不過看不管某些人說點空話騙人，估計這種人也是這樣呼悠客戶的。
[h]實在鄙視 [h]

实体的设计有问题。
issue是一个实体，他的属性应该是值，而不是属性的修改日志。
举个例子：记事本是个实体，记事本的内容是他的属性。当你取得一个记事本的时候，你要看他的内容（当做属性时）是一个值，可能是“明天下午2点开会”；如果你想看都有谁修改过记事本的内容，那应该是一个修改内容的日志，类似于“小魏，4.2，下午下雨；小张，4.3，中午吃肯德基。。。。”。所以，日志本质上就不是记事本的属性。
所以设计上应该是：
记事本：记事本内容
记事本内容修改日志：人员；时间；修改内容

强烈鄙视那些只谈设计的ren，在怎么ddd也不可能把日志当做集合属性吧，这和考勤当做员工的集合属性有什么分别呢，谢谢。
再有，既然纯的oo是不考虑数据库的，只考虑对象，那为什么还要把数据放到库里呢？为什么还要优化hibernate的性能呢？谢谢，再次。

上页
下页