大家都在讨论Hibernate,难到他没有缺点???

如weblogic提供了WebLogic-QL Extensions:

• ORDERBY for sorting on the database side when this feature is available, which is
faster than sorting on the client side.
• GROUP BY for grouping results on the database side when this feature is
available, which is faster than grouping on the client side
• Sub-queries, for example SELECT… WHERE x > (SELECT …).
• Multi-column ejbSelect queries, for example SELECT field1, field2 …,
with the result being returned as a java.sql.ResultSet.
• Many numeric aggregate functions:
• MIN(field)
• MAX(field)
• AVG(field) and AVG(DISTINCT field)
• SUM(field) and SUM(DISTINCT field)
• COUNT(field) and COUNT(DISTINCT field)

还提供了:
Dynamic Queries
Dynamic queries:
 enable executing arbitrary EJB-QL queries at
run time
 are ideal when the queries are not known at
design time

Client code Snippet:
...
AccountHome acctHome = (AccountHome)ctx.lookup("AccountEJB");
Sring ejbql = "SELECT OBJECT(a) FROM AccountBean a " +
"WHERE a.accountType = ’Savings’";

QueryHome qh = (QueryHome)acctHome;
Query query = qh.createQuery();
Collection results = query.find(ejbql); //returns Account objects

WebLogic-QL Examples:

A Few Examples:
SELECT OBJECT(a) FROM AccountBean AS a ORDERBY a.accountId ASC
…gets accounts ordered by account ID.
SELECT OBJECT(a) FROM AccountBean AS a
ORDERBY a.accountType; a.balance DESC
…gets accounts ordered by account type, and then by descending balance
SELECT MAX(a.balance), MIN(a.balance) FROM AccountBean AS a
GROUP BY a.accountType
…gets a list containing the biggest and smallest balance of each account type
SELECT DISTINCT( MIN(a.balance) ) OBJECT(a)
FROM AccountBean AS a GROUP BY a.accountType
…gets a list containing the smallest balance of each account type, with no repetition
SELECT OBJECT(a1) FROM AccountBean AS a1
WHERE a1.accountType = %1 AND a1.accountId IN
(SELECT a2.accountId FROM AccountBean AS a2
WHERE a2.balance > 0)
…gets accounts of a certain type, for which the balance is grater than zero.

EntityBean毕竟对事务的处理非常灵活,可以进行声明.
还有提供了相应的cache,pool,read-only等特性.

你列举了那么多Weblogic-QL和EB的特点真让我觉得好笑，看来你是从来没有仔细看过Hibernate的文档，你说的那些Weblogic具有的特点，Hibernate实现实在容易得很阿，而且HQL无非就是sql的翻版而已，何况Weblogic-QL还不是EJB的标准。

Hibernate不过是JDBC的PreparedStatement语句的封装而已，和EJB没有什么可比性，拿它来和JDO做对比显得合适一些。Hibernate做为ORM有一些固有的缺陷，比如批量Update和Delete的效率问题，不过这些问题EJB也一样有。Hibernate大的毛病几乎没有，至少我还没有发现，小的毛病也有不少，去Hibernate官网的Bugfix列表去看看就知道了。

不是标准是缺点。
想用，就需要学习，是缺点。
用了，就得永远使用它的鼻孔出气，也是缺点。
还有，如果用了Hibernate ，ApplicationServer用什么，好像tomcat就可以了。
但是，凡是大的项目，商业的项目，都不可能用Tomcat。那就用Weblogic ，WebSphere ，iplanet 。十来万的application Server，由于Hibernate搞掂了一切而成为摆设，你只是用它作为Servelet引擎，数据库连接池，其实是当Tomcat用了岂不可悲？我想这也是缺点。

一旦用了Hibernate，这个自成一体的东西，如果有一天你回心转意，决定回到EJB上来，你会发现它很难和EJB容在一起，你不得不全面彻底改写。
反过来，如果我是采用JSP，Servlet，JavaBean，Taglib来根据CoreJ2eePattern来组织应用，在合理规划的前提下，只需要加入新的持久层，就可以了，修改虽然不可避免，但应该不用彻底修改。

我们现在正面临这样的修改需要，改起来还是比较简单。

看了一下，感觉没啥意思，功能很强大，其中的道道太多
学习起来很费劲，不如jdbc来的爽。
而且和 EJB server的相容性？？？？

>> 看了一下，感觉没啥意思，功能很强大，其中的道道太多

不管你是想批评，还是想赞扬一种软件，前提条件是你必须对它有充分的了解，否则的话，只会让人感觉你没有严谨的态度，而是在夸夸其谈。

>>学习起来很费劲，不如jdbc来的爽。

确实没有JDBC简单，Hibernate入门容易，掌握精通我也不敢自夸。我第一遍看Hibernate文档的时候也觉得很吃力，但不是因为Hibernate难掌握而感到吃力，是因为Hibernate文档处处都是持久层设计的经验和最佳实践。Hibernate文档准确的来说，绝大部分内容都在讲对象的持久层设计，而不是简单的Hibernate使用，使用问题查Java doc就够了。所以学习Hibernate，主要是在学习持久层的设计模式，如果你把Hibernate文档都看完了，还整天只会提那些Hibernate的配置问题，Hibernate的类调用问题，我觉得这样的人还没有真正的入门，算是白学了。

我对Hibernate的那些配置也不是特别纯熟，每次写hbm，都要对照文档一点点的检查；类调用参数也不太记得，写代码也要Java doc随时备查。但是我在学习Hibernate的时候即集中所有精力来理解Hibernate的运行原理，集中精力来掌握持久层设计应该把握的原则和技巧，这些才对我是最重用的东西。毫不夸张的说，学习完Hibernate，我对JDBC的编程也提高了一大截，更不要说对于J2EE架构的持久层的框架设计，基本上是了然于胸了，即使将来换了API，不用Hibernate的，改用JDO，Castor什么的，这些经验一样照用。

>>而且和 EJB server的相容性？？？？
这话说的很无知，说明你根本没有用过Hibernate。只有EJB才存在和EJB Server的兼容性问题。

>> 不是标准是缺点。
制订一个标准，然后大家的产品都不兼容，这叫做灾难！

>>想用，就需要学习，是缺点。
我晕！照这么说，知识就是缺点！

>>用了，就得永远使用它的鼻孔出气，也是缺点。
我再晕！你用了电脑，就一辈子使用它的鼻孔出气，也是缺点，所以我们大家不要用电脑了。

>>还有，如果用了Hibernate ，ApplicationServer用什么，好像tomcat就可以了。
我n多次强调，Hibernate是JDBC的轻量级封装，凡是你用JDBC的地方，都可以用Hibernate。照你这么说，用了JDBC，ApplicationServer还用什么？

>>但是，凡是大的项目，商业的项目，都不可能用Tomcat。那就用Weblogic ，WebSphere ，iplanet 。十来万的application Server，由于Hibernate搞掂了一切而成为摆设，你只是用它作为Servelet引擎，数据库连接池，其实是当Tomcat用了岂不可悲？我想这也是缺点。

这说明你根本不了解什么叫做App Server，你只把App Server === Servelet Container + 数据库连接池 + EJB Container。简直可笑！

>>一旦用了Hibernate，这个自成一体的东西，如果有一天你回心转意，决定回到EJB上来，你会发现它很难和EJB容在一起，你不得不全面彻底改写。
无语！没有用过的Hibernate的人在狂言呓语！

>>反过来，如果我是采用JSP，Servlet，JavaBean，Taglib来根据CoreJ2eePattern来组织应用，在合理规划的前提下，只需要加入新的持久层，就可以了，修改虽然不可避免，但应该不用彻底修改。

你真的理解什么是持久层了吗？你真的知道包含Hibernate的持久层应该怎么设计吗？

如果你对Hibernate持有异议，如果你觉得Hibernate有缺陷，那么拜托你的帖子有点深度好不好？我也很想知道Hibernate有哪些缺陷，曾经以为的很多缺点都随着对Hibernate的功能的进一步了解而解除了。目前我对Hibernate确实有一个还没有搞清楚的问题，我不知道这是不是Hibernate的缺陷，但因为没有足够的测试环境，所以还不能确定，因此不敢乱说。

但对于那些连Hibernate都没有怎么用过，对J2EE整个软件架构设计都不甚了了，甚至对App Server都缺乏正确的认识的情况下，胡乱发表批评意见，我对这种夸夸其谈的肤浅的态度感到愤怒。

Robbin，说那么多名词，懒人们不懂，简单点说吧Hibernate就是JDBC，能用到JDBC的地方就能用它，用JDBC就会封装数据库操作，Hibernate就是个最好的封装框架，省得自己花功夫了

>>但是，凡是大的项目，商业的项目，都不可能用Tomcat。那就用Weblogic ，WebSphere ，iplanet 。十来万的application Server，由于Hibernate搞掂了一切而成为摆设，你只是用它作为Servelet引擎，数据库连接池，其实是当Tomcat用了岂不可悲？我想这也是缺点。

>这说明你根本不了解什么叫做App Server，你只把App Server === Servelet Container + 数据库连接池 + EJB Container。简直可笑！

原来AppServer还有很多很多功能。。那不是浪费的更多？

>目前我对Hibernate确实有一个还没有搞清楚的问题，我不
>知道这是不是Hibernate的缺陷，但因为没有足够的测试环
>境，所以还不能确定，因此不敢乱说。

说出来也无妨啊！我看能不能帮你测试。

上面回贴情绪有点激动，希望谅解，我不是因为有人批评Hibernate而感到不快，而是因为帖子里面的观点实在让我觉得荒谬。不管觉得Hibernate好也吧，不好也吧，我唯一觉得遗憾的是，在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread，跟了几百贴，其中包括Hibernate作者Gavin和LiDO JDO的CTO，对于JDO和Hibernate有过一些激烈的争论，我曾经耐心的看了一遍，仍然没有发现针对Hibernate真正有力的攻击，那些所谓的攻击无非针对Hibernate没有一个GUI的配置工具，没有商业公司支持，没有标准化等等这些站不住脚的理由。

补充几点我的意见：

一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。

二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。

三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：

传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。

2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。

3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。

4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。

四、EB和Hibernate学习难度在哪里？

EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。

Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。

当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。

Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？

这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。