robbin，其实hibernate也不能做到session关闭后继续使用阿，比如我有懒装入的属性，而且hibernate那些能让你对待对象和集合的方式来操纵数据库的前提都是session存在，我个人不喜欢这种某些情况下成立而某些情况又要另外考虑的东西，从这点透明方面讲，EB更透明。
更不用说远程了，现在的方法VO是不能被PO完全代替的，VO的另一个作用就是取PO的的子集进行传输，在很多情况下远程传输一个大对象，特别是它引用一大串其他的对象就更够呛。
嘿嘿，这个问题我是精心研究过的，你说的基本都不对。
>>更不用说远程了，现在的方法VO是不能被PO完全代替的，VO的另一个作用就是取PO的的子集进行传输，在很多情况下远程传输一个大对象，特别是它引用一大串其他的对象就更够呛<<
在Hibernate中，PO就可以完全取代VO，在Hibernate的设计理念中，PO都是fine-grained，如果出现很庞大的的PO，那首先是设计的失误，另外它不会出现引用一大串其它对象的情况。
>>其实hibernate也不能做到session关闭后继续使用阿，比如我有懒装入的属性，<<
当使用lazy initialization的时候，只有在分布式环境，远程客户端调用EJB，从EJB端想要获得包含集合属性的PO，才需要在程序里面考虑lazy initialization的情况。但是这也很简单，在服务端EJB返回PO之前，把客户端需要的集合属性initial一下就好了，具体来说就是Hibernate.initialize(...)而已。所以很简单，你只要记住如果是有集合属性的PO，调用返回前initial一下，如果不需要用到集合属性就什么都不用做，直接调用返回。
>>而且hibernate那些能让你对待对象和集合的方式来操纵数据库的前提都是session存在<<
不需要Session存在，举个明显的例子吧，在分布式环境中，EJB端连接数据库，配置Hibernate，而远程客户端除了放置EJB接口文件和Hibernate PO文件，其它什么都没有。你可以在客户端new一个个PO对象，然后序列化传给EJB，然后EJB开一个Session，向数据库增加；你也可以在EJB里面开一个Session，查询数据库，获得PO对象，然后关闭Session，最后把PO序列化传送给远程客户端，客户端可以修改这个PO对象，可以对PO的集合属性做任何想做的操作，最后还可以把改好的PO序列化返回服务端EJB，EJB另开一个Session，向数据库update一下。
你在客户端可以自由的按照你想用的任何方式使用PO，你不需要Session的存在，你甚至不需要知道服务端有Hibernate的存在。
其实你没完全明白我的意思
我并不是说hibernate的PO不能当成远程传输，我也知道在EJB中如何做，我的意思是PO不能*完全*取代VO,VO的一方面作用就是按需要取domain对象的部分数据远程传输到客户端，比如我的PO有8个属性，在一次调用需要用到的是4个属性，一次调用中需要的是6个属性，一次需要8个属性，因为远程传输是比较昂贵的，所以VO可以只携带部分数据，而hibernate的PO在一次装载之后就已经装载了所有属性（它不能懒装入同一个对象的某个属性），也可能包括引用的对象。如果你将hibernate PO直接传输给客户端，每次都传输了所有的属性（你也不可能把hibernate的PO的某个属性不需要设置为NULL之类的，很可能把数据库也消了），如果按需传输数据，而又直接复用服务器对象模型，Rickard Oberg论述过动态代理的实现，而简单的用hibernate是不容易办到的。
我说的“hibernate让你象处理对象和集合的方式来处理数据库数据”意思是这样的，比如hibernate讲可以增加一个数据按此方法，比如child.getParents().add(obj)就可以为它增加了一个父母，和内存对象操作一样，但是如果关闭了session，能办到吗？不能“自由的按照我想的任何方式”的使用PO，和session存在时不同。
把对象远程传递前把所有懒装入的属性都初始化，此时对应用已经不具有透明性了，有的需要初始化，有的不需要初始化，也可能初始化很多我在客户端并不需要的东西，比如一个大集合，既消耗数据库又消耗网络。还是那样，简单的hibernate直接传输不方便，如果要在客户端享受懒装入，就得对传输的PO做手脚才行。
我随便的感受，没有推敲，也没精心研究过（因为我对关系型数据库持久不是非常感兴趣），错了也无妨，hehe。
你说的VO实际是现在谈得多的 DTO,Data Transfer Object，DTO可以根据要求实现动态DTO，将需要放入这个集合。
有试过torque吗？turbine的持久层就是用它的。不过对事务支持的不好。
关于那次讨论，实际是先进的非标准技术和成熟的标准技术之争。这个争论本身实际是毫无意义的.
我主要是发现一些言论是会产生明显误导倾向，或根本是错误的，特别是对于框架的认识等，所以我才会在这方面进行了反驳。只是由于争论双方无法站在对框架统一认识的基础上，所以我没有继续讨论下去，但是我放弃讨论不代表我承认一些观点。
这个讨论不是EJB本身设计优缺点的讨论，技术本身是中立的，EJB是J2EE重要而复杂的技术，在很多大型系统包括ebay（收购易趣30%）已经运行多年，这些都证明EJB本身优点是大于缺点.
当然任何技术都有缺点，否则技术不用发展，但是我们需要把一种人为的缺点和正常的缺点区分开。
所谓人为的缺点，就是没有学会正确使用EJB，或者胡乱使用EJB，导致EJB项目失败，如果从这方面认为EJB是有缺点的，那是片面和错误的，我本人也非常反感这种武断的判断，因为这会误导更多EJB初学者。
jdon网站近期将会完全使用Struts+EJB+CMP（DAO）框架实现更新，包括论坛，所有这些都是无非想从实践角度来证明成熟技术的合理使用是多么重要，在Java中，设计模式 、思想和框架远远重于java语言本身甚至其具体的技术。
O/R Mapping产品也无法是向有利于对象化、进而有利于框架设计这个方向发展，但这里面还是有一个标准的问题。
在Java世界，之所以是百家争鸣，显得乱，但是不失去章法，关键是有标准，有SUN为主导倡导的标准，这是java世界生存的基本之道，目前这个标准只有偏弱，而不是过分，有人预言，Java的最大问题可能由于其乱了失去章法，自我毁灭，所以标准在Java中是主心骨，非常重要的地位，虽然SUN没有从标准中获取多少利润，但这种精神值得很多著名的软件公司来学习的。
JDO 2.0作为标准，有很多ORM领域专家参与制定，他们制定的标准和EJB一样，应该是成熟，而且是对用户负责的。
Jdon论坛欢迎更多来自实践原创讨论，而非抽象空洞的争论，这也是我以前很少发表这些方向性问题言论的原因，但是没有这些高度问题的正确讨论，这个阵地就会被错误言论替代，从而误导用户，最综对java本身产生伤害，这是作为一个专门为Java设立网站的Jdon所不愿意看到的。
希望这些抽象问题讨论到此结束。谢谢配合。
关于Hibernate技术问题讨论请到Robbin的网站www.fankai.com进一步讨论。
本贴为最后结贴，谢谢配合。
CMP作为EJB规范的一部分，其在兼容性，支持方面都自然不错。但是显然，这是一个重量级的O/R方法。学习曲线陡直，且应用复杂，特别是对于初学者；在很多较小项目中，用这种重量级的方法显得比较本末倒置。在cmp2.0以前，Entity bean的效率一直是问题。对于cmp2.0的效率，我已经很久不用CMP了。
现在的JDO标准也是一个较好的轻量级选择，其简单易学，API较少，对象映射简单，是初学者比较好的选择。但问题也多多，查询功能太弱，对象关系模糊，更致命的弱点是调试困难，由于其是通过增强class来实现的，绝大部分供应商代码又不公开，实现方式千奇百怪,给调试带来了极大的困难。半年前，我在一个项目中应用JDO,为此换了三个产品:jdogenie,kodo,lido。发现每个产品都有自己的问题，实际也并非其所吹的“全面兼容”（规范规定的必须兼容），有的问题甚至很严重，导致稍微复杂点的查询都不能实现。看来，在简单的项目中应用JDO还可以，稍微大一点的就不行了。
Hibernate学习的曲线相对也较陡峭，但上述所有缺点都没有。要吃午饭去了，以下简单描述几个好处
效率不错
运行时增强
查询功能强大！
对象关系清晰！
源代码公开！
如果你实在不能选择，其实还有DAO嘛，封装一切底层具体的o/r实现，采用DTO解决VO和PO的问题。这样可以灵活选择O/R产品。
当然，世界上的O/R工具很多，我不能也不可能详尽介绍。有机会上ERPROAD做进一步讨论。国庆节过后，我找一下各种O/R工具的对比专门的网站。
祝开心。
http://www.erproad.org
> 我碰到的情况是一个制造行业的ERP软件，80多个表还是极端?> 化的了，原来则是150多张表，再怎么组件化，还是很难避免?> 要将几十个表之间需要连接查询的情况。
有个问题请教：
我原来做过Oracle Application 11/11i的客户化开发，曾经碰到一家客户，IT部负责人很变态，想把一些报表做成WEB形式可以访问和打印的，这导致了Oracle的D6i（Report Builder6i）很难弄，Oracle的Application系统的表有几K张，视图也是几K张，出张报表有时候要先创建若干个中间视图和工作表，然后写pl/sql进行处理，最后用Report去出报表，本来是没有什么问题的，但是弄到WEB上（加上格式等其他元素）就变得很头大，这个时候H有什么可以帮忙的？
> N层结构没有任何问题，问题的焦点在于是否必须把逻辑放到
> 中间层，中间层做个web server，所有逻辑放到数据库一层
> 中间层通过简单的jdbc调用存储过程，传入参数，所有参数解
> ?> 都在存储过程里，这样中间层对数据的处理异常简单。同时继
> 辛?> N层体系的优点。
> 我觉得根本不是hibernate v.s. CMP
> 而是store procedure vs (hxxx and cxxx and xxxx..)
> 骑自行车时大家都有体会，低头看近处便于掌握路况，骑一会
> ?> 抬抬头，看看远处要到的目标，远近结合着，如果只看眼前，
> ?> 会骑到糜子地里。作技术就好像低头看近处，时不时应该看看
> ?> 己的目标，你做项目是为了项目而技术还是为了技术而技术？
> ?> 最短的时间内已最低的成本达到客户的要求就是软件项目的成
> Α?> 而在这方面n层结构+调用存储过程完成商务逻辑是一个很不错
> ?> 选择。根本没必要用hibernate、CMP，搞笑死了，我看到的随
> ?> 一个企业级的项目光数据表就5、6百张，表和表之间复杂的关
> ?> 关系，以其一张一张做映射，或者通过hibernate作相对很简?>
> [相对存储过程]的数据操作指令，还不如去编个toad自己玩。
>
>
> 以上言论并不是否定了hxxx,cxxx技术，而是相对procedure来
> 担?> 它们离database太远了，复杂的数据操作会让你吐血的，真地
> ?> procedure进行数据操作形象的比喻就是“那数据都是自家地?> 产
> 的，不值几个钱”，一个字儿“方便”：）
> hxxx,cxxx是发展方向，它们只是一个构思，还没有成为现实?> 没
> 有成为成熟的现实），面包会有的，牛奶会有的，但是！！
> 记住！，现在没有！，现在，就用procedure吧。
有点共鸣！
我非常喜欢这种方式，不仅方便而且效率高，适合做ERP系统。
我们公司有个针对中小型企业的ERP系统，用Oracle Dev6i作的，用的就是这种模式。后来我还曾想：是不是可以把每个功能模块的执行顺序也放到SP里面，这样在界面上就是简单的执行调用了，以后业务上有什么修改都跟界面这个“外壳”没有任何关系了，只有改动SP就可以了，可惜没被采纳！
天，我头一次遇到这么长的讨论，我整整花了1个半小时看完，我是在google上找Hibernate的分布处理找到的，好像在这里有了答案，但不确定对不对：
web->session bean->hibernate就可以处理分布式的事务了，对吗？
to guty,robbin
guty,robbin两位大哥,能不能写个使用了hibernate的简单实用的示例给看看啊,最好是基于Web应用的,比如注册模块,购物车之类的,只要基本实现增,删,改就行了,如能提供经典的分页功能更好,最好别省代码,完整点,供我们入入门吧,谢谢,tjyhy590@sina.com
我想说几句
EJB不是只有cmp和bmp, 比较cmp/bmp与hiberate之间的优缺点是不是更好？不要总是扯上EJB
到今天，EJB3还是采用CMP，还叫CMP，将来在持久层有一个统一标准，将在Java EE 5中颁布，
优点：
Hibernate代表的O/R mapping比CMP更加符合对象化建模，但是CMP也是符合建模设计，使用过Borland的architect软件就知道了。
无论使用Hibernate或CMP，都是必须符合对象化建模的设计思路，否则都可能糟蹋了这些技术；或者用不好怪技术不好。
这里是一个真正Hibernate高手的心得：
http://www.jdon.com/jive/article.jsp?forum=16&thread=22244
如果你没看懂，说明你需要更加好好学习，而不要被暂时的繁话美景迷惑，你有自己的判断权，可是你判断正确了吗？这也就是我为什么今天写这个帖子的目的：
Hibernate其实和CMP一样，由于不是精确的缓存（这也是为什么大量读取时推荐DAO模式一样），导致大量查询时性能很低：
见这个帖子：
http://www.jdon.com/jive/thread.jsp?forum=62&thread=24197
其实本帖的很多言论是hibernate 创建者Gavin King在TSS的讨论，要得到更多原创有见解的言论，到TSS(http://www.theserverside.com)读英文去吧。
这个讨论时隔三年来看还是有收益，当前EJB3推出后，目前正在统一JPA，支持EJB3的JBoss使用Hibernate3来实现EJB3的CMP，说明Hibernate3的事务可靠性已经达到完成CMP或JPA的所有功能，Weblogic使用JDO开源产品Kodo来实现EJB3的JPA;而Oracle则使用toplonk来实现JPA。
CMP Hibernate JDO 已经统一在JPA旗帜下，殊路同归，持久层技术争论也归于平静，现在Java世界转向业务层技术的争论，Spring/RoR/Evans DDD动态语言是一个热点。
这个帖子要更新了
现在ejb3 jpa出来了
又要讨论一番