> to robbin
> 如果谁把10个以上的CMP放在一个EJB
> Module里面设计，那么他就没有充分理解EJB组件的概念。
软件的原则是不错的，但是可能你谈论涉及到的领域主要还是局限在Internet应用上，像Web Forum，Portal，KM等等，这还是比较简单的情况。数据库表最多超不过30个吧，而且彼此之间的关联也不会那么复杂，还是比较容易分的。
我碰到的情况是一个制造行业的ERP软件，80多个表还是极端简化的了，原来则是150多张表，再怎么组件化，还是很难避免需要将几十个表之间需要连接查询的情况。
JBuilder也是我最喜欢使用的Java IDE工具，基本上不用其他IDE，但也只用JBuilder来做EJB，其他的统统用UltraEdit，现在基本上不写代码，就更加不用了。
另外用盗版的JBuilder的用户小心了，JBuilder9会自动悄悄的向Borland发送消息，听说很多使用Borland盗版软件的公司都收到Borland的律师信了。
>关于在ThreadLocal中保存transaction，你没有仔细说明Transaction何时创建，何时提交，我理解为是创建Session后，立刻创建Transaction，web层调用都结束后，提交Transaction，关闭Session。这样，可以写一个Filter来专门处理提交Transaction和关闭Session。
的确是这样：）
>我做了一个简单的试验，用Hibernate查询MySQL数据库，反复查询500次数据库，做统计。由于只是查询数据，因此是没有必要使用Transaction的，经过比较，使用了Transaction之后，平均查询时间多了600ms，也就是说平均每次查询要多1ms的时间开销。而在我的AMD Duron700的机器上，MySQL数据库的CPU占用率从19%上升到24%。
非常好，我也很喜欢这种实践做法。
>所以我觉得可以把你的方案再改良一下，Filter就不用改了，检测一下tx不为空才提交。而HibernateSession.currentSession()可以给它传一个参数，比如说只查询数据，不修改数据库的时候，给它传0，光创建Session或者取Session，而不启动Transaction，不为0的时候才启动Transaction。
这也是一种好方法。或者在filter中根据配置文件确定方法是否需要transaction。
>我觉得你好像概念稍有混淆，Web Server的Cluster是Web Server的Cluster，而App Server的Cluster是App Server的Cluster，在一个大型Web应用中，完全有可能Web层进行Cluster，来分担繁重的HTTP请求，而App Server也进行Cluster，来分担繁重的业务运算，这是不搭界的两回事。
我也发现我的概念越来越模糊了。我现在觉得很多应用中，没有必要把App Server和Web Server分开来，从技术架构来说，如果Web Server里实现了Transaction,O-R,Cluster，那它不已经具备了App Server的功能？
>如果是单纯的Web应用，会话是在Web层实现的，使用HttpSession，而不需要使用Stateful Session Bean，但是单纯的Web Server本身不能进行HttpSession的Cluster吧？只有ServletContainer才提供的吧，比如Weblogic的HttpSession的内存复制技术。
可以这样理解吧，WebServer提供Cluster，ServletContainer提供Session in-memory copy?
Hi, Jevang
>If I can do it, why those much smarter Hibernate people can't do it?
I think the Hibernate Team only concentrate on their product, and the problem is maybe only robbin and mine problem. Anybody smart like you could find an ideal solution.
And I totally agree with the other parts of your post.
Regards,
guty
>交易安全性优先：
>Session Facade -> Stateless Session Bean -> DAO -> O/R Mapping
>性能优先：
>Session Facade -> Java class -> DAO -> O/R Mapping
我现在的想法是简化开发优先:)
其实我对目前的企业管理软件的开发，有自己的一些小想法。
现在大家都说三层架构如何如何先进，但很多人应该心知肚明，现在的开发效率、软件成熟度，比起c/s开发模式来差得远了。我经常会怀念过去用delphi开发程序的时代。
所以，我理想的三层架构开发模式，是参照c/s来的：
1. 以前的database，现在用java object可以完全覆盖，enity对象做o-r，service对象负责逻辑（象sp一样，尽量少）。
2. 以前的Client GUI，现在是Web程序。和成熟的C/S开发一样，这一层应该大量采用数据绑定技术来简化数据维护和开发，不拘泥于什么MVC，可以直接在界面代码中使用hql这样的查询语言，尽量精简service对象，而选择直接对entity对象进行CRUD操作。OGNL（object graph navigation language) 是很值得使用的技术。
除了一二之外，应该尽量减少其它多余的层次。
to robbin:
>我碰到的情况是一个制造行业的ERP软件，80多个表还是极端简化的了，>原来则是150多张表，再怎么组件化，还是很难避免需要将几十个表之间需要连接查询的情况。
你可能误解我的意思，我说的原则是细化，不是简化，150多张表可能还嫌少，你把它简化成80张表，那耦合性当然更强，无法以组归类这些表。
150张表不能每张表之间联系都紧密，肯定有一组表主要完成某些功能，另外一组表完成某些功能，而且以EJB Module划分后，不是说组件之间不能互相调用，还是和放在一起一样的，只不过是分类的手段，日常生活中，我们也会经常这样做，学校人多了，就划分年级，班级，部队人多了就分军区 师 甚至班，这些本来是正常对待客观世界的方法论，本来就应该一样应用在软件工程中。
关于三层架构的开发效率和成熟度，好像一直怀疑，其实很多事情是需要进一步研究，在J2EE下还需要针对本领域进行自己领域的框架设计，针对各个层，做好框架，web表现层按照Struts，那么Action Jsp开发就很模块化，中专生都可以做，你设计好web与EJB的接口框架，那么专门搞EJB的编程也会很模块化，就是在一个session facade完成特定实体bean 的增加 查询 删除修改，这些中专生都会做，到时由一定经验的设计人员组装起来，马上能跑通，安全机制也是有设计人员直接配置容器，无需编程。
btw: Jbuilder 9确实有问题，我对比过，狂占内存，同样系统比JB8多50M内存，我已经改回JB8，Boland公司大概被微软搞得脑子是有问题了，JB7 JB8 JB9三个版本中，JB8算能用的。
banq，你好！多装点内存不就得了，我的机器是512MB内存，对内存不敏感。不过CPU就是慢点。JB9运行EJB Designer的时候，慢得像老牛。JB9支持struts开发，还是很方便的，界面也漂亮很多。JB9启动的时候就打开8000端口监听，不知道干什么用，是不是和Borland通信用的？还好我也只是拿JB来研究用的，不用它做开发，现在已经删了。
guty，在页面里面嵌入业务层，甚至数据处理代码，可是bad smell阿。如果你真的这么倾向于简化开发，我强烈建议你采用.net，而不是j2ee。
不知道大家想过没有，发明Java的Sun公司从来都不是一个软件公司，做Unix工作站起家的，就是现在主营业务还是硬件。所以设计出来的Java，并没有过多考虑，或者根本不去考虑简化开发，简单易行的方案。但是Sun特别重视框架设计，强调设计模式。看看Sun的《Core J2EE Pattern》玩模式有点走火入魔了。都按照它上面的模式做软件会累死的。
之所以这样，大概是因为Sun一向从事的是企业高端，中高端领域应用，在这个领域里面，最重要的是稳定性，安全性，可扩展性，和异构系统的可兼容性，性能反而是放在后面考虑的问题，至于开发效率，这样的大型软件开发周期都会非常长，更加是一个不敏感的问题，甚至是被忽略的问题。
这样的高端大型的软件，你不强调分层能行吗？必须不遗余力的降低软件模块之间的耦合度，分层越细越好，层次越细，软件的维护成本，和二次开发成本都非常低。
另外这样的大型应用还有一个特点，就是需求不会有非常大的改变，而且改变的也不频繁。
而Sun发明的Java，特别强调软件的架构设计，强调设计模式，不都是完全为了适应上述类型软件开发的特点吗？
反过来看看MS，做桌面软件起家，他更关心的是软件开发的速度和效率，他设计的.net处处强调对于开发人员的易用性，对于软件应用的简化，可以说是为开发人员和快速软件开发量身打造的工具。比如说C里面还保留struct，而Java就是Value Object。如果你仔细研究C#，就会发现C为了开发的方便和简化，牺牲了很多作为一个OO编程语言的严谨。
对于MS来说，他不太重视，甚至忽略软件架构设计的重要性。所以用.net的程序员会觉得入门好简单，开发好快捷。据我了解，同样的需求，用.net开发效率是j2ee的三四倍。
如果你有兴趣去看看.net petstore，会发现它在ASP+页面的事件处理的cs程序里面就直接调用ADO.net来访问数据库，这和guty的主张真是不谋而合。但是在Java的世界里面这不是被允许的坏的程序实现方式。因为一旦页面处理流程改变了，连业务代码，和数据处理代码全部都要跟着改，小应用无妨，大应用就要死人了。
也许你还会想到，现在的应用，需求变更是不可避免的，而且一变都是大变，加上很多Web应用本身需求就不是非常非常精确的，就算你设计出来的架构分层分得很好，耦合度再低，可是需求变动一大，由于软件本身的业务流都变了，你还是得全部都改。既然如此，还不如不分层，尽量简化开发，来适应快速，多变的软件需求呢！
特别是对于很多接项目做来赚钱的软件公司，首要目标就是把软件做出来，可以运行，把钱拿到，这是最重要的。所以项目开发周期优先考虑，加上客户今天要改一个需求，明天要改一个需求，需求自始至终都在变。在这样的情况下，容得你从容的进行架构的软件，分层分模块的严谨的遵守软件设计模式的要求来实现吗？当商业目标比技术目标优先考虑的时候，你必须使用快速原型开发，用最快的速度做出一个可用的东西来再说。当钱赚到了，你自然可以慢慢得考虑技术上的分层，优化的问题。
所以.net完全是应运而生的产物，特别适合于快速原型开发，你可以在极短的时间里面做一个跑起来的软件，大多数情况下，这样的软件甚至都可以交差了。在中国IT软件业，这么浮躁，行业这么不稳定的情况下，.net比j2ee更能迎合软件公司的需要。
不过如果你是一个ISV，并且要做自有产权的行业通用软件，从开始进行一个良好的架构设计是软件开发成功的必要保障，在这样的情况下，j2ee比.net方便面要优秀很多。
在.net中，如果有意识的进行架构设计，当然也会提高软件的可维护性，复用性，但是没有j2ee在概念上分得那么清楚，支持的那么自然流畅罢了。
由于.net和j2ee内在固有的特性和适用的场合，精通j2ee的人，自然而然的以考虑软件架构为重，而.net的人，自然而然的以考虑软件实现的方便快捷为重。可以说是互有短长，各有适合的场所。
拿Web开发来说吧，j2ee提倡MVC，并且有struts这样的成熟的MVC架构，所以设计人员首要考虑的是软件模块的划分，把每项功能单独分离出来，每个被分离出来的功能使用一个Action来实现，该功能的显示使用一个JSP来显示。完全是基于面向对象的软件模型驱动的设计和开发模式。
而.net的Web Forms的设计理念正好反过来，首先考虑的是用户操作的流程，把用户操作的流程总结为一个个的ASP+页面，然后为了让这些页面动起来，每个页面绑定一个专门响应和处理页面事件的cs程序。完全是基于面向用户交互的由用户触发事件来驱动的设计和开发模式。这种开发模式其实已经非常类似于传统的C/S开发了，由GUI的事件驱动编程。而MS Visual .net Studio还专门做了一个“所见即所得”的拖拉Web控件，然后对Web控件绑定响应事件进行编程的环境，和C/S开发几乎没有什么区别。
从这个简单的例子中，就可以看出两者考虑问题的出发点各有不同，而guty从你的需求来说，.net web forms似乎更适合你。
另外struts的主要负责人现在也是Java Server Faces的项目组长，而JSF和web forms一样，也是页面事件驱动的编程模型，而此人也是建议大家将来从struts转到JSF上来。
不过我个人不倾向于页面事件驱动的模型，因为一旦用户的操作流程发生改变(而这样的改变在Web应用中比较频繁，反到是传统的GUI界面操作流程轻易不会改动)，整个程序就要大动，可维护性不是很好。
关于hibernate JDO等推荐下面的文章：
http://www.rollerweblogger.org/page/roller/20021013
刚找倒的，呵呵，目前正研究hibernate，并准备用其作为当前项目的persistence framework，还想用下xdoclet，不过中文资料好少啊：（
有这方面高手的请赐教：）
MSN:l_walker@hotmail.com
robbin将j2ee和.net比较一下，很多观点我是不同意，但是争论也没意思，只是想重复声明一点的是：
设计模式是为可重用而服务的，所以GOF的设计模式书叫 可复用面向对象软件的基础。可复用面向对象软件是软件发展趋势，不是java单个语言，Java虽然是SUN公司发明，但是完全是整个软件业集体智慧的产物，在这点可以举出很多证明，我们不能因为对公司的好恶来影响软件的看法。
在GOF 设计模式这本书里已经谈到框架、组件，这些都是软件业发展的需求，只不过Java出现得比较及时，正好符合这种需要，而微软在这方面是断档的，这是全世界公认的。
框架、组件、模式恰恰是为了面对变化的需求，也就是说，是不断灵活变化的需求促使软件业诞生模式、组件和框架，至于为什么说这些能够应付变化，可以说很多，说白一点就是一句话：将我们能掌握的握在手心（模式、组件和框架），全身心力开发满足不断变化的需求。
详细的说,J2EE解决了实际项目很多公用的问题：事务机制、安全机制、数据库操作等等，有了这些有力和丰富的工具，你面对变化的需求能害怕吗？
再说白点，框架、组件和模式更倾向于软件经验和理论的升华，对于中国平均程序员只有26左右来说，理解掌握这些是不可能的事。
很多人因此放弃java学习微软的.net，其实微软.net真正核心也不会逃脱模式、组件和框架这个软件理论，为什么微软让人觉得好上手，因为他的语言是在老的语言上发展起来，不喜欢模式、框架组件的人也会按照原来过程化思路设计软件，最后标榜自己是.Net，但是这些虚假的把戏在Java中就无法上演，后者从运行性能和稳定性等各种问题上报复你。
>CMP可以使用CMR来表示多表之间通过外键关联的关系。
>但是你仍然会遇到即使没有键关联的表仍然需要连接查询的情况，这是一个非常普遍的现象。
>如果是Hibernate，可以在HSQL里面定义outer join，BMP也可以写JDBC，而CMP没有任何办法来解决该问题，
>除非你把需要的连接查询都定义为CMR，但那样的话，凡是有需要连接查询，
>或者有键关联的表都必须打在一个包里面。
>你如果不打在一个jar包里面，如果能够建立CMR？
>不是我想放在一个jar里面，而是不得不放在一个jar里面。基本上CMP还是非常笨拙的。
首先CMP按照目前的规格是不可能全包所有的应用，应该说CMP和BMP是互相补充，在CMP CMR以及EJB-QL不能尽力
情况下个别选择BMP，这样降低开发难度，提高速度。
>CMP的另一大缺点是不能动态SQL，guty已经提到了，
>一个SQL就要定义一个EJBFinder方法，
>其实JDBC的PrepareStatement也不能很好的解决这个问题，
>因为它是按照1，2这样的次序来set参数的。
>用Statement是肯定不行的，会严重影响数据库，甚至会导致数据库down掉(我的实际经验)。
>但是Hibernate就解决的不错，因为它可以按照 :name 这样的形式来设定SQL中的Placeholder，
>这样set参数就可以按照参数名称传递，因为次序不是死的，
既然JDBC作为底层都没有解决这个问题，Hibernate解决了，是因为它通过它的组件解决了，
只不过无需你编程，但是性能如何就很难说了，O/R mapping的东西目前最大的优点就是好用，但是
同时带来最大缺点是性能问题，很简单，它在你的应用和JDBC中间加了一层，如果这个中间层做得不好
还不如不要，直接使用JDBC更块，BMP就是这样的选择。
>CMP2.0还有一个大问题是不支持order by，
这个问题SUN出EJB2.0时特别提到，因为有Collection，所以不提倡使用实体层的排序，如果有这个功能，其实这也是
换汤不换药的做法，如果你针对具体应用做出适合自己的优化排序性能能不高吗？
这个排序功能可以在以前我们讨论的数据库返回Iterator中完成，属于value List模式。
我确实怀疑hibernate这种包办的做法，性能问题是所有O/R mapping必须面临的最大问题。
>其实和BEA和IBM的工程师接触过，他们会建议你不要轻易使用Entity Bean的。
>Stateful Session Bean也是一个很慢的东东，考虑到大多数情况下是纯Web应用，
>不需要用Stateful Session Bean，我个人倾向于这样的业务层架构：
正好相反，看看weblogic架构师http://www.theserverside.com/events/videos/DeanJacobs/transcription.html
的发言，回答正好和这些BEA或IBM工程师相反，在一个集群环境中，尽量少使用http session
因为随着服务器台数增加，复制这些session会浪费耗费性能，最好是Web层无状态，将状态
实现在有状态Session bean中，一般一个系统只需要一个，利用EJB本身的集群机制（不是简单复制session），
可以大道很好的集群性能。
真是爽，新技术不辩不明阿。
robin,
佩服佩服，文章越写越长，我想我是说不过你了:)
>guty，在页面里面嵌入业务层，甚至数据处理代码，可是bad smell阿。如果你真的这么倾向于简化开发，我强烈建议你采用.net，而不是j2ee
后台当然还是Java，从商业上来说，这可以让系统支持高端的服务器环境，少受病毒影响；从技术上来说，也熟悉很多。所以WebForm是不可能用了，但我希望能够自己开发出RAD能力更好的框架，慢慢积累吧。
至于桌面客户端，我真的很想用.net，但现在不确定.net在客户端的部署能力，所以还在用C++。但C++对Webservices的支持不好（包括7.0)，不支持复杂数据类型（Complex Data Type)，需要对Java接口有很多限制。
另外，我不是很同意你关于高端软件必须分层的说法。事实上，J2EE出现后不久，J2EE的RAD开发就成为一个很热门的话题。MDA，POJO，AOP很多思路都是为了简化J2EE，BEA、Sun等厂商也都非常重视RAD工具的研发。
其实，如果技术的架构真正优秀，应该可以设计出比visual studio更为优秀的RAD工具。例如eclipse和refactoring就比vs好的多。
>首先CMP按照目前的规格是不可能全包所有的应用，应该说CMP和BMP是互相补充，在CMP CMR以及EJB-QL不能尽力情况下个别选择BMP，这样降低开发难度，提高速度。
这样做的结果是让程序员同时有两套思维，一套是应付EJB的，一套是应付JDBC的。
>同时带来最大缺点是性能问题，很简单，它在你的应用和JDBC中间加了一层，如果这个中间层做得不好还不如不要，直接使用JDBC更块，BMP就是这样的选择
O-R mapping的最大作用不是分布式，不是安检，而是O-R mapping。让程序员能够完全用面向对象的思维来分析和设计系统，让系统能够支持多种不同的数据库平台。EJB的那些功能反而是跑题了。
>我确实怀疑hibernate这种包办的做法，性能问题是所有O/R mapping必须面临的最大问题
对order by,group by,outer join的支持简单的很，不就是从hql到sql的转换吗。这种improvement对hibernate来说只需要一星期，对EJB来说需要一年，这是hibernate为什么实用的原因。
>正好相反，看看weblogic架构师http://www.theserverside.com/events/videos/DeanJacobs/transcription.html的发言，回答正好和这些BEA或IBM工程师相反，在一个集群环境中，尽量少使用http session因为随着服务器台数增加，复制这些session会浪费耗费性能，最好是Web层无状态，将状态实现在有状态Session bean中，一般一个系统只需要一个，利用EJB本身的集群机制（不是简单复制session），
可以大道很好的集群性能。
我也看了，文章也没有建议不用http session啊，而是说stateful sessionbean是支持transaction的，所以它的in-memory copy可以在transaction提交时批量进行，而http session的in-memory copy则不能这样（'more offen',应该是指在修改后立刻copy，而不是说需要同步更多的数据）
关于不建议使用SFSB，我到是也看到BEA的Tyler Jewell（Director, Technical Evangelism）很久以前发在onjava上的文章Stateful Session EJBs: Beasts of Burden（http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html)。
文章并没有否定SFSB的作用，而是强调了它的误导性，容易导致不正确的使用（例如cache）。这也是我对复杂技术的看法 - 没有必要，而且容易导致错误。其实SFSB的功能和http session类似，而http session几乎不需要学习，非常容易掌握。和CMT一样，SFSB非要把原本已经很成熟很简单的概念包装起来，用厚厚的spec去长篇大论。缺点是显然的。
>在GOF 设计模式这本书里已经谈到框架、组件，这些都是软件业发展的需求，只不过Java出现得比较及时，正好符合这种需要，而微软在这方面是断档的，这是全世界公认的。
我记得Design Patterns早期的版本是C++的，然后才有了Java版本。组件技术上，DCOM和CORBA早在EJB诞生之前，就进入企业实际应用了。
>再说白点，框架、组件和模式更倾向于软件经验和理论的升华，对于中国平均程序员只有26左右来说，理解掌握这些是不可能的事。
这到是，但建议改成“完全理解掌握这些是不太可能的事”。
>不喜欢模式、框架组件的人也会按照原来过程化思路设计软件，最后标榜自己是.Net，但是这些虚假的把戏在Java中就无法上演，后者从运行性能和稳定性等各种问题上报复你
软件开发上有一条著名的准则是K.I.S.S. - Keep It Simple, Stupid，XP开发里强调不要over-engineering。
模式、框架说到底只是工具，需要用就用，不需要用可以拿过来扯大旗，但千万别太当真了。
banq，你好！回复如下：
一、我并没有因为对公司的好恶影响我对技术的判断。
坦白来说，我对MS和Sun全都没有好感，MS的垄断就不用说了，Sun的不思进取也让人不爽。我真正很有好感的公司是BEA，我个人希望BEA能够成为Java领域的旗手，而不是IBM。
二、理论和实践有一定差距
J2EE严守软件架构设计的理论，但实践执行起来，未免死板了一些。.net就灵活变通很多，很多地方的设计是不符合理论要求的，但是这样做就提高开发效率，带来很大的方便。
就好比关系数据库的设计，没有哪个DBA会严格遵守3个范式，总是会设计很多冗余字段，来提高查询效率。我对.net这样的方式持肯定态度。
三、j2ee和.net的比较
我曾花了很多功夫研究.net，从技术上来说.net没有任何优势可言，但是不要忘记，在IT发展历史中，技术先进的东西消亡，而技术落后的东西发展壮大的例子太多了。比如说IBM的OS/2 vs MS Windows，比如说DEC的Alpha vs Intel Xeon。对于两种技术的此消彼涨，更多的要取决于商业市场上的较力，赢得市场者赢得天下。再加上MS的老奸巨猾，.net总是一个让你不能忽视它存在的力量。
MS原来在企业开发领域是没有能够和j2ee相竞争的技术架构，但现在有了.net，.net融合了以往MS所有的技术成就，同时也吸取了很多j2ee的优点，我一直想写一遍文章详细的从技术和商业角度探讨两者的，这里不多谈了。
从技术角度来讲，我喜欢j2ee，不喜欢.net，因为Java语言非常严谨，让我享受到了软件设计的艺术美感，但从个人职业生涯来说，我宁愿做一个骑墙派，从商业角度来看问题，而不要因为个人的技术好恶影响我的判断。在一个具体项目中，从技术，从成本，从开发周期，从维护各个方面综合考虑，谁优就用谁。
四、可复用面向对象软件(模式)迄今为止，并不是非常成功。
请看Sun的《Core J2EE Pattern》这本书，我把中文版原话引用在这里：
“至今，我们追求软件重用的目标已经多年，但没有取得很大的成就。实际上，绝大多数业务重用的成功例子都发生在用户接口领域，而不是业务组件领域，而后者才是我们努力追求的目标。”
现在用java开发的框架已经非常广泛了，但是主要还是面向技术架构的框架，面向业务的框架确实很少有成功的，也许Ofbiz是一个？所以，业务改动太大的话，业务组件重用不了，还是得重新写。
特别是Internet开发，很多时候都是在需求不明确的情况下开发软件，一边根据用户反馈来调整需求，我以前在一个Internet公司做这样的开发做了一年半，在这样的情况下，你必须用快速原型开发，快速做一个Demo出来比考虑架构，重用重要的多。技术人员必须要有商业头脑才行，在商业目标优先的情况下，必须放弃自己的技术原则，牺牲软件性能，架构。这个问题不多谈了，社会意义太重，不适合在技术论坛讨论了。
五、CMP和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写死在配置文件里面了，你连选择的余地都没有。
六、O/R Mapping性能
我不知道为什么你这么怀疑O/R Mapping的性能，O/R Mapping的性能再差也比CMP强吧。
JDO只是一个标准，每个厂商实现的性能各有不同，不好评价。
Apache OJB的性能如何，Apache网站上面有评测。
Hibernate的性能我是花了点时间去研究的。Hibernate可以通过修改配置文件把所有的SQL语句都输出出来，你写一些测试代码观察一下输出的SQL，就什么都明白了。
简单的来说，Hibernate的性能比一个普通的Java程序员写的JDBC代码性能高非常非常多。原因是因为Hibernate本质上还是包装了JDBC来进行数据库操作的，由于Hibernate在调用JBDC上面是非常非常绞尽脑汁的优化JDBC调用，并且尽可能的使用最优化的，最高效的JDBC调用，所以性能相当令人满意。
简单来说吧，对于insert操作，普通JDBC程序员这样来写：
pstmt = conn.prepareStatement("insert into table1 values(?,?)");
for (int i=0; i< names.length; i++) {
pstmt.setString(1,names);
pstmt.setString(2,pass);
pstmt.executeUpdate();
}
如果批量插入n条记录的话，那么就是n次向数据库发送SQL语句。而Hibernate则是采用了JDBC2.0的batch功能。
for (int i=0; i< names.length; i++) {
pstmt.setString(1,names);
pstmt.setString(2,pass);
pstmt.addBatch();
}
pstmt.executeBatch();
只是1次向数据库发送SQL，性能高下判若分明。Update操作类似。
select操作，可以使用JCS缓冲查询结果，重复查询比JDBC肯定要快很多，分页操作使用JDBC2.0的scroll result。
另外Hibernate总是尽量延迟向数据发送SQL，它会先把SQL语句缓冲在Session的缓冲区里面，最后在flush的时候一次性的向数据库发送。
总体来说，当你使用Hibernate的时候，相当于有一个JDBC高手来帮你优化JDBC调用，那点封装了一层的损失可以忽略不计。
如果你非要认为Hibernate封装了JDBC会损失性能，那么我问你，Java设计的目标是组件可复用，这些不全都是封装吗？难到你调用组件都损失性能了，如果是那样，还不如不要写什么组件，全部都重新写原始的实现代码呢！
不过如果一个真正的JDBC高手，完全自己优化JDBC代码写DAO实现，我相信会比Hibernate性能高一些，但是Hibernate已经够优化了，你能够做的是非常有限的。就好比用C语言写的程序，虽然比汇编语言差一点，但是差的非常有限。Hibernate vs JDBC就相当于C vs Assemble，除非特殊需要，Hibernate已经足够好了。
不轻易相信别人的话，通过自己的思考和实践来判断，这种精神我很赞赏，我不会试图说服你非相信我的话不可，但我相信当你深入全面的研究和测试了Hibernate之后，会有一个满意的答案的。
七、正好相反，看看weblogic架构师http://www.theserverside.com/events/videos/DeanJacobs/transcription.html的发言，回答正好和这些BEA或IBM工程师相反
这个问题怎么说呢？其实你想过没有，BEA和IBM就是靠卖昂贵的能够跑EJB的App Server赚钱的，否则不早被那些便宜的开源的又不要钱的Java App Server取代了？如果他们的工程师敢在公开的场合宣传不要用EJB，他们是不是活得不耐烦了？还想不想在公司继续干下去了。我刚好在某行业No1的跨国大公司干过，明白一些大公司的内幕，呵呵，不继续说下去了。
to guty：
1、试试Java Server Faces吧，说不定适合你。
2、Web Services
Web Services我去年研究过，还替人招刀写了某Web Services书的其中一章，如果不是为了整合异构系统，我建议你不要采用Web Services。
我的建议是仍然用Java开发桌面客户端，AWT和Swing确实太慢了，但是你可以采用SWT，相当不错，完全采用JNI调用Windows底层图形库，速度快，内存消耗少，界面完全是Windows本地桌面风格。Eclipse自己就是用SWT做出来的，已经相当好了。然后不要用Sun JRE来跑桌面应用，用IBM JRE，速度可以进一步提高。
采用Web Services会带来好多问题：
1、无状态
你每次调用服务端组件都要把状态信息用参数的方式发送给App Server，为此，你还必须在App Server端仔细的设计如何把业务组件良好的封装为Web Services。但不管怎么说，每次调用都要传状态信息，实在太蹩脚了。
Apache SOAP 比较独特，它把状态信息封装在HTTP Cookie里面发送，虽然是个好办法，毕竟不通用。如果你服务器，或者客户端任何一方不采用Apache SOAP，就有得麻烦了，还要自己写代码解析HTTP协议和SOAP协议。
2、不安全
至今没有良好的安全保障机制
3、速度慢
SOAP调用的速度并不是非常慢，经SOAP封装的EJB方法调用，我的经验是由几十ms级降到几百ms级，还可以接受。但是SOAP调用的速度受客户端和服务器端的XML解析器性能的影响非常大，如果你用的XML解析器不灵的话，会非常缓慢。
4、异构系统的可维护性
使用Web Services，客户端实现技术和服务端是不同的，而且还必须把服务端的组件封装为Web Services供客户端调用，这种整合异构技术的方式会带来很多不必要的复杂性，同时提高维护的成本。
总体来说Web Services还非常不成熟，在某些Internet上面使用还有其优势，因为Web Services封装了不同的组件实现方式，使不同技术实现的组件都能用统一的方法来调用和互调用，比如说EJB组件可以调用.net组件，反过来也一样。不过做企业软件，采用单一技术方案会更有把握，尽量不要给系统引入复杂因素。
这个论坛有bug啊，帖子里面的方括号变成了斜体的标示符，把我前面帖子里面的程序代码片断里面的方括号都吃掉了，呜呜！
版主，我翻了一下历史帖子，发现你对.net有偏见。我也想对你说一句你同样对我说过的话，不要因为对公司的好恶影响你对技术的判断。就算你再不喜欢.net，但是在你对.net下结论前请花1周以上的时间深入研究一遍.net，因为我发现你对.net的结论有些是明显错误的。
在Java论坛说.net的好话好像确实容易遭到攻击，但我是站在客观的，不带任何偏见色彩来评价j2ee，.net的优点和缺点的，长处和短处的。对我看不顺眼的，先安装一个Visual .net studio，写一周.net代码再来和我争，我不惧！
Java低手们最担心的事情是j2ee被.net淘汰了，白白投资了时间和精力去学习Java，所以想了解j2ee和.net的未来趋势，好选择明智的道路。
Java高手们涯岸自高，根本不屑去了解.net这出自MS之手的东东。
其实最简单的办法就是去学习.net。像.net这种学习曲线这么低的东东，投资一点时间，特别是j2ee高手，学习起来简直是探囊取物，因为.net实在太像j2ee了，你要学的仅仅是两者在实现方式上的差异而已，你的j2ee知识用来了解.net一点都不浪费
j2ee <-> .net
JRE vs CLR
JDO vs ADO.net
JSP vs ASP+
EJB vs COM+
JMS vs MSMQ
JSF vs Web forms
所谓他山之石可以攻玉，这笔投资是很值得的，而且.net确实有很多比j2ee做更好的地方。