各位老大，你们能谈谈CMP和Hibernate哪个更好一些吗？

[peihexian]

我想知道选择哪一个更好一些。

[wandou999]

无所谓好与不好,用你擅长的,一般来说用Hibernate比较多

[tianlujun]

学习中

[okitgo]

各有优点, 不过我用CMP

[jimaojian]

以前用EJB，现在感觉到一般的应用都没有必要用这样的东东，所以现在该用HIBERNATE，感觉还不错，
其实他们都有他们的好处和缺点，怎么说呢，如果你的应用，不是大型的分布系统，我建议用HIBERNATE，也许系统性能要好些，你可以试一下。

[linuxbing]

学习。
现在用Hibernate处理联合主健问题比较麻烦，其他到是方便的很。

[yeshucheng]

呵呵，到这里学学我老乡的东西：）
对hibernate不懂，还只是停留在网络的资料上

[shangqiao]

走马观花

[sgdb]

hb更灵活吧，
不过我今天被hb折腾了一下午：（

[IceCraft]

至少目前来看，hibernate在代码维护方面的缺点有：
hibernate提供了自动生成mapping文件“框架”的工具，但还需要手工调节。而这类开发，能想到的最佳模式就是xdoclet的（代码+注释）的模式了。幸好，hibernate的程序员已经向xdoclet项目增加了hibernate的模块。现在需要的是等待xdoclet的下一个 release。
从整体方案来看，如果说不使用Session Facade模式的话，我认为Entity Bean还是一个很有意义的的东西，因为Entity Bean是唯一直接支持跨RMI的持久化方案。但是由于Entity Bean的效率和减少跨RMI的网络调用的原因，Entity Bean已经完全被封装到Session Bean的后面，Entity Bean的分布式调用的功能，安全验证功能，容器事务功能完全被前面的Session Bean给做了，结果Entity Bean就只剩下了唯一的ORM功能了，单就ORM这一点来说Entity Bean实在是一个非常糟糕的东西。那么Entity Bean还有什么功能值得我非去用它不可呢？
用 Session Bean + DAO + Hibernate 来取代 Session Bean + Entity Bean，不但能够极大降低软件设计难度，软件开发难度，软件调试难度和软件部署难度，而且还可以提高允许效率，降低硬件要求。
不要把Entity Bean直接拿来和Hibernate做比较，两者不是一个范畴的东西，而应该整体比较两种方案：
Session Bean + DAO + Hibernate
Session Bean + Entity Bean
很难找出第二方案有哪怕一点方面能够比第一方案好的。
CMP可以使用CMR来表示多表之间通过外键关联的关系。但是你仍然会遇到即使没有键关联的表仍然需要连接查询的情况，这是一个非常普遍的现象。
如果是Hibernate，可以在HQL里面定义outer join，BMP也可以写JDBC，而CMP没有任何办法来解决该问题，除非把需要的连接查询都定义为CMR，但那样的话，凡是有需要连接查询，或者有键关联的表都必须打在一个包里面。你如果不打在一个jar包里面，如何能够建立CMR？不是我们想放在一个jar里面，而是不得不放在一个jar里面。基本上CMP还是非常笨拙的。
CMP的另一大缺点是不能动态SQL，前面已经提到了。一个SQL就要定义一个EJBFinder方法，在编译的时候就确定死了。在实际应用中，经常会遇到不确定查询条件的查询，比如说用户在页面上用下拉列表来选择查询的条件，用户既有可能什么限制条件都不选，也有可能选择某几个条件。这时候你怎么办？假设有n个查询条件，你要写 C1n + C2n + C3n +...+ Cnn(C是组合公式的符合，n是下标，1...n是上标)个EJBFinder方法才行，很恐怖吧。
其实JDBC的PrepareStatement也不能很好的解决这个问题，因为它是按照1，2这样的次序来set参数的。用Statement是肯定不行的，会严重影响数据库，甚至会导致数据库down掉。但是Hibernate就解决的不错，因为它可以按照 :name 这样的形式来设定SQL中的Placeholder，这样set参数就可以按照参数名称传递，因为次序不是死的，在程序里面就很容易根据用户选择的查询条件，动态的产生SQL，动态的set参数了。
CMP2.0还有一个大问题是不支持order by，当然你可以在Java里面对取出来的集合排序，但是速度和数据库里面就排好序速度不在一个数量级了。Hibernate不但可以order by，还可以group by，having，子查询，真是没有办法比下去了。
其实对于动态SQL和排序问题，特定的App Server也可以做，但那不是CMP2.0的规范罢了，所以为了可移植性，也不敢随便去用。
在项目开发时，开发和运行效率以及灵活性是非常重要的指标。由于Entity Bean天生是一种粗粒度的使用方式，这就必定使它在装载的时候有较长的响应时间，也不能自如的支持懒装入的方式，使用成细粒度会使程序变得复杂，以及远程调用细粒度的entity bean是一种非常可怕的行为, 太慢了。
Hibernate正好满足开发和运行效率以及灵活性，说来说去，它可以称做一个OO化的JDBC, 这样大家就不会对Hibernate产生误解及恐惧心理。它支持粗细两种粒度方式，运用起来灵活自如，前提是你必知道如何使用，一个entity bean实现要N种重复的方法, 诸如ejbRemove，ejbstore，ejb....，光类也有一大堆，象Home Interface, Romote Interface...， 如果需要Primary class，Hibernate只需要一个就行了。
CMP在进行O/R Mapping方面只是做了最基础的工作而已，完全用CMP做数据层，会发现在把数据库应该做的工作全部都搬到App Server里面来重新实现一遍，有这必要吗？
CMP是把EJBQL写死在ejb-jar.xml里面的，所以n个条件就需要(c0n+c1n+...cnn )2的n次方个EJBFinder方法，简直没有办法说。
JDBC实现PrepareStatement的动态SQL构造不是不能够，而是非常麻烦，需要写一个非常非常大的if elseif else嵌套的判断。
Hibernate实现起来特别简单，（其实OJB也实现了PrepareStatement的动态SQL构造）这本身并不复杂，但是需要多写些代码而已，由于CMP把EJBQL写死在配置文件里面了，连选择的余地都没有。
总体来看，Hibernate完全符合我在第三章末提到的我们需要的开发模式的几项标准，即：
一、 开源和免费的License，我可以在需要的时候研究源代码，改写源代码，进行功能的定制。这样就不需要投入大量的资金去购买EJB组件了。
二、 轻量级封装，避免引入过多复杂的问题，调试容易，也减轻程序员的负担。简单的设计，快速的开发，这正是我们所需要的。
三、 具有可扩展性，API开放，当本身功能不够用的时候，可以自己遍码进行扩展。
四、 开发者活跃，产品有稳定的发展保障。
同时，HIbernate也解决掉了CMP的大部分缺陷，而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方，它不仅仅是Hibernate的功能介绍那么简单，它实际上是一个持久层设计的最佳实践的经验总结，文档里面的例子，文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是，不单单把Hibernate的关键点掌握住了，而且对持久层的设计的经验都长了一大块，以前可从来没有觉得持久层的设计还有那么多的学问，也由此感觉到Gavin绝对是一个大牛人。
当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少，而且写的非常简洁，我总觉得挺奇怪的，这么少的源代码能够实现这么多的功能，是个奇迹。通过对几种开发方式的深入接触，我觉得用Hibernate让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。
后来的实践证明，选择Hibernate是正确地。在整个开发过程中，Hibernate逐渐显现出了它强大的优势和魅力，真正是轻量级的、开发灵活的、全局易控的。

[fatcatman]

mark

[yeshucheng]

可能Hibernate的灵活性更强点

[pbMaster]

一个是轻量级，一个是重量级。
说穿了就是一个更灵活，一个更死板。
我自己的观点是：各有优点。
比如CMP开发起来更快揭，而HIBERNATE开发更灵活。
HIBERNATE是界于CMP和BMP之间的东西。比CMP灵活，比BMP方便。
在实际的使用中，如果没有具体的要求，可以用CMP+HIBERNATE（取代BMP），不要被HIBERNATE的鼓吹者迷惑。用CMP实现简单的持久化，用HIBERNATE实现复杂的查询（关联复杂，数据量大等）

[AlexSunny]

Hibernate,ejb各有各的好处！看你自己的需要吧

[mudsong]

Hibernate没有缺点?

根本不用担心性能，等你了解Hibernate就知到了

关联复杂的问题，使用面向对象的思想，关联复杂迎刃而解
完全可以N层关联

[mudsong]

引用robbin的原话

一、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之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。

[peihexian]

好，就这么定了，sb+dao+hibernate。在ejb 3.0出来以前先用这种模式。