我刚刚开始接触Hibernate不慎了解，对于EJB用了一段时间，大致说说我的看法。

首先我不太同意用EJB和Hibernate直接作比较，正如前面有人提到Hibernate犹如php一样，它的特点就是快速，灵活，方便。然后EJB 就不一样，他的一个前提就是Enterprise，而在Enterprise的环境下首要考虑的因素并不是Hibernate特点所具备的，当然我不反对从Data Mapping的角度来比较这个问题。
EJB 的最大特点就是分布的，安全的，事物的，其重点并不在于一个简单的数据库映射

从前面的讨论可以知道Hibernate的不具备分布和安全的特性，具有一部分的事物特性，然后这个事物似乎是建立在JDBC的transaction的上面，几乎就是jdbc的connection。但对于一个复杂的应用系统来说仅仅只有JDBC的trasaction是不足够的。因为在复杂的应用系统中提倡的是组件化开发，而不同组件的事物常常涉及到相互调用的问题，很明显，如果不在一个处理过程中的事物出来在hibernate来说是很难实现的，所以我不同意前面有关EJB的事物处理是一个弱点的说法。
之所以出现EJB的事物互锁的情况，我看绝大多数原因在于开发和部署人员的素质问题，和EJB的体系没有太大的关系。

至于以后企业开发的规范中是否会使用类似于Hibernate更高效灵活的数据绑定方式，那是肯定的（EJB 2.1的规范中已经支持order by的操作）。然而就单单从数据绑定的角度论述谁优谁劣没有太大的意义

不过，不知道有没有人使用过expresso的，也可以说是一个ORM 的framework吧

我只用过hb所以就不废话了嘿嘿。。（已经废了很多话...）

同意Robbin的观点，表格太多的时候复杂关联会让JBuilder的可视化界面变得和蜘蛛网一样
而且定位器方法是EJB的鸡肋，我的理解：定位器方法是为了Session Bean操纵Entity Bean而设置的
但实际中很多查询工作也要通过定位器方法实现，这个时候，死板的定位器方法就很差劲了，往往要写很多定位器方法，而且很难做到动态查询

顺便，说说我对数据库的看法：
数据库是商业软件产品，一个商业软件产品必然会不断发展！
这点很重要，所有体系结构设计也罢，设计模式也罢，都一相情愿
的认为数据库只是完成数据存取等基本数据操作。殊不知数据库本
身也在不断发展，oracle也不会只在传统数据库方面发展，必然会
借助自身数据库作为载体，不断朝其他领域扩展，正因为在一个真
正的企业及应用中，数据占有极其重要的地位，因此数据库厂商在
朝其他方面扩展时，难度要小得多。因此，我觉得大家应该去了解
数据库厂商开发的中间件产品。

在电信的许多应用中，性能和稳定性是第一位的，就像我们去年有一个项目，各省往全国中心传数据，每家300多兆，要半个小时，性能上差个一倍两倍可不是闹着玩的。

但三层架构出现自然也有他的意义，企业管理软件由局域网延伸到Intranet甚至Internet上的需求确实是越来越多，不用三层架构，客户端维护、人员培训、信息同步的成本都难以降下来。

O-R也由它的作用，编程上是否方便姑且不论，支持不同数据库的确是很多项目的竞争点。

我也是做计费的，我就喜欢把所有的业务逻辑都放在数据库里，在数据库里操作数据是一件很惬意的事情。
高效，强大，甚至编程量和发布都很方便。
当然除了业务逻辑以外，jsp还有很麻烦的叶面逻辑，我是放到struts或着其它bean里，但是这些东西都比较容易自动生成了。
对于性能的问题，我不敢说，别人都认为把应用放在中间层，然后分布出去对性能好；我自己觉得不要把数据取来取去的直接在数据库里操作至少节省网络资源。
至于加大数据库的负担，反正我们客户的并行访问量不会超过10个人同时访问数据库，主要是操作的数据量比较大，因此现在还不是问题。
但是到底哪个更经的起大量并发访问和大批的数据处理我就不好说了。

以上言论并不是否定了hxxx,cxxx技术，而是相对procedure来说，
它们离database太远了，复杂的数据操作会让你吐血的，真地。
procedure进行数据操作形象的比喻就是“那数据都是自家地里产
的，不值几个钱”，一个字儿“方便”：）
hxxx,cxxx是发展方向，它们只是一个构思，还没有成为现实（没
有成为成熟的现实），面包会有的，牛奶会有的，但是！！
记住！，现在没有！，现在，就用procedure吧。

是的，我非常同意你的观点。
各种技术都有其优势所在，应该是根据实际需求采用最适合的技术。依靠一种技术打遍天下是不现实的，尤其是象数据库这样的。

存储过程是一门很实用的技术，在速度上不是一个量级的，在写以存储过程为基础的项目也非常整洁清楚，一个业务点就是一个存储过程。

多一层是为了灵活，但是在以速度至上的系统中，存储过程估计是无可替代的。

我的理解不管是CMP、BMP还是hibernate都是有两个目的：
１、完成O/R mapping
２、实现数据的本地化

对于1、完成O/R mapping。如果真的作到了很好的O/R mapping，那么的确不错，但是对于写数据的时候，O/R　mapping还是比较麻烦的。现在的技术似乎也不是特别成熟。特别是对于强大的sql语句，任何面向对象的语言都会逊色。如果只是简单的把表mapping到java容器里，再在许多复杂的对象间匹配数据，我觉得程序写的再好也没有直接访问数据库作的好，毕竟人家数据库厂商做的就是这个。

对于２、实现数据的本地化。其实理想的状态就是等于在内存里作一个数据库，所有的操作都在内存里进行，最后保存到真正的数据库服务器只是为了持久化为了备份而已。其实我觉得这个功能的实现似乎是应该数据库厂商来做。而且我觉得数据库厂商也一定有类似的内存缓冲机制，那么就是看我们调用数据库接口是不是消耗效率了。
当然还有一种情况，如果这个内存里的数据库查询功能有限，需要直接访问数据库作报表的话那么数据的同步就是一个很需要商榷的问题。

当然我对EJB了解很少，我只是知道一点用J2SE＋数据库编程的方法。我站在如果是让我自己实现EJB的功能我最好能作到什么，这么做值不值。

我只是想到就说到，不知道自己的观点对不对，希望有一个的大哥站出来批判我一下。

骑自行车时大家都有体会，低头看近处便于掌握路况，骑一会儿
抬抬头，看看远处要到的目标，远近结合着，如果只看眼前，就
会骑到糜子地里。作技术就好像低头看近处，时不时应该看看自
己的目标，你做项目是为了项目而技术还是为了技术而技术？在
最短的时间内已最低的成本达到客户的要求就是软件项目的成功。
而在这方面n层结构+调用存储过程完成商务逻辑是一个很不错的
选择。根本没必要用hibernate、CMP，搞笑死了，我看到的随便
一个企业级的项目光数据表就5、6百张，表和表之间复杂的关联
关系，以其一张一张做映射，或者通过hibernate作相对很简单
[相对存储过程]的数据操作指令，还不如去编个toad自己玩。<<

你说的话太极端！希望你深入的掌握中间层技术再下结论，不要那么轻率。中间件技术出现的很早，甚至比关系数据库出现的还要早。在数据库里面处理复杂的逻辑，效率固然很高，但是要看到的问题是，数据库处理的逻辑完全是数据驱动的逻辑，对于那些强调算法的逻辑，比如说电信计费，银行结算什么的，非常适合，但是对于那些算法简单，但是步骤特别烦琐的非常强调行业流程的商业型逻辑并不适合，甚至来说，这样的业务，大部分情况下都是处理表的CRUD操作，和多表之间关联的CRUD操作，你根本就没有什么store procedure可写的。这些业务需要的是需求模型驱动，而不是数据模型驱动，你用数据驱动的模型是处理不来这些业务的。

况且把所有的逻辑都放在数据库里面实际上是牺牲了可移植性，并且耦合性极高。

对于很多ISV来说，软件产品不能只绑定到一个数据库上，在Oracle里面你能把所有的数据处理逻辑放进去，换了别的数据库，你可能由于数据库本身不支持，就根本做不到移植性，就算能够移植，毕竟由于数据库支持的功能，sql语法差异太大，你等于是在重新开发一遍。

而且在数据库里面放入过多的业务逻辑，会造成耦合性过高，一旦软件业务小有修改，就是整个数据库层的大手术，甚至还要波及到上层的调用代码的大面积修改，那就是很麻烦的事情了。

我是反对把所有的业务逻辑都放在数据库层的（实际上很多业务型的项目，你也没有什么可往数据库层放的东西），应该根据实际情况，那些算法复杂，数据处理密集的数据处理逻辑适合放到数据库层，而流程复杂的，需求驱动的业务处理逻辑适合由中间层来处理。