神马文学网给大家一个锻炼脑子的机会：EJB有什么好处？ Java / J2EE / EJB / JMS
来源：百度文库 编辑：神马文学网 时间：2024/05/24 01:16:41
- 给大家一个锻炼脑子的机会：EJB有什么好处？
我们先从Sun推荐的EJB开始。大家可以来讨论，EJB究竟有什么好处。我希望参与的每个人动脑子，从自己的经验中去寻找答案，不要到Mastering EJB或者别的什么现成资料里面去抄。这类资料我比这里大多数人都看得更多。
问题点数：0、回复次数：253 1楼 Schlemiel (维特根斯坦的扇子)
m
Top2楼 filippo1980 (管药师★(加班中......))
我觉得没什么好处，在中国开发EJB纯粹是蒙人的！
基本是公司为了坑客户的钱才搞什么EJB。
开发Entity Bean的失败率又高，开发成本又大周期又长。劳民伤财！
个人意见，发发牢骚。不要打我
Top3楼 naomaomao (孬毛毛)
呵呵，正要学习，听听高手们怎样讲~~：）
Top4楼 bon_jovi (西门疯雪)
就是分布式，自己去写rmi麻烦。如果都放在一个jvm里实现了，就没有必要用ejb。
Top5楼 Schlemiel (维特根斯坦的扇子)
话不能这么说。很多人知道我并不推荐EJB，我是轻量级方案的推崇者。但是EJB作为Sun非常重视的一种方案，它仍然有它自己的优点。作为一个称职的开发者，我们有必要丰富自己的工具箱。没错，你今天可以直接在JSP里面写所有代码，在特定场景下这是合适的做法。但等你的客户成熟起来，等他们的需求复杂到一定程度，你愿意继续像个傻瓜一样在JSP里面写所有代码吗？
Top6楼 kevinliuu (@_@)
我做听众 ：）
Top7楼 jinsfree (蓝色天使)
只能听,没有用过,不过好多人说还可以,只是对其中的实体bean有颇多微词
Top8楼 bon_jovi (西门疯雪)
主要为了分布式吧。
也可能是因为容器提供了事务，安全，池，开发者没必要过多关心这些，省心。
Top9楼 yorkchen (york)
我也觉得 没有好处
Top10楼 zcjl ()
没做过EJB
搬凳子停课了
Top11楼 jokerjava (冷血)
东西都让中间件做了 不放心 呵呵
Top12楼 asdmonster (呆鸟四号)
楼主， i 服了 u
Top13楼 freelyl (飞翔)
感觉是骗钱用的。没什么别的。又难又烦
Top14楼 leeak (JavaHappens)
觉得 要实现分布式 EJB还是首选的
不知道其他兄弟怎么想的
Top15楼 Leemaasn (呆鸟)
我先伸一下腿踢一下场子，看有没有什么反应。。。嘿嘿。
Top16楼 hqchen ()
只做过会话bean,我只知道我省了管事务的心,其他还真不知道
Top17楼 VVV_lucky (*太阳*)
有吗？
没有。
有吗？？
没有。
有吗？？？
没有。
有吗？？？？
没有。
有吗？？？？？
没有。
有吗？？？？？？
没有。
有吗？？？？？？？
何必那么激动呢，探讨探讨。
Top18楼 zcjl ()
哈哈
太阳也太不嫌麻烦了些
扇子牛人很少发帖
不灌一下真是过意不去！！
：）
Top19楼 sagittarius1979 (※2+2=5※)
听说过这么一句话，“EJB是sun彻彻底底的谎言”。呵呵！
Top20楼 usabcd (9号公路上的3名共军)
偶用过一段时间，笨重。尤其是entity bean 即使用CMP方式也不灵活
感觉没什么实际用途。主要是想不出有什么必要非要这样做的理由。
开发繁琐（编译部署缓慢），维护困难。它的分布式功能，在绝大多数项目中好像用不上。
而MVC的概念，不用EJB也可以实现得很好。我觉得没接触的同志，了解一下就可以了。
有这功夫不如钻研下 strut Hibernate 等东西实用些。
Top21楼 swallow999999 ()
我赞成usabcd的说法，但是安全性确实不错
Top22楼 locust2002 (蚂蚱)
骗人，骗人，烦人，没用
Top23楼 zhxx (做个好流氓有多难)
1.容器提供了事务管理
2.学习资源较多，开发工具也很多
3.ejb有很多商业公司支持
Top24楼 usabcd (9号公路上的3名共军)
1.容器提供了事务管理
2.学习资源较多，开发工具也很多
3.ejb有很多商业公司支持
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这些说得都没有错，十分的有道理，不过，衣服只有穿在身上才感觉合不合身。
如果你拿它做过几个正规的中型以上的项目，如果还对它的有点如数家珍，赞不绝口，
那我就没话说了。
事务处理它是提供了，但算不上是个什么大不了的优势，大部分的项目，仅靠数据库本身的
连接的事务处理就足够了。只有在跨数据库操作时才用得上。这种情况很少，即使有也可以
手工写代码搞定。
学习资源多并不见得开发效率就高。不用它用其他方式资源更多，做过项目就会有切身体会。
至于商业公司支持也事另外一码事了，我不用EJB照样可以跑在商业公司的 App Server上,
而且性能更好。
对了，开发费时费力是一方面，
EJB还有一个比较重要的问题，性能问题。如果一个大的系统有数百乃至上千个表，
如果用Entity Bean，试下看看，嘿嘿，仅仅光挂上100个 Entity bean 还不要说业务逻辑Session Bean
app server就很辛苦了。（免费的jboss挂到30个都吃力），这个也许算EJB的硬伤了。
不知有用过的兄弟能否讲讲性能方面的体会啊。
不过我个人的体会，搞EJB可以让人在开发的过程中开始思考一些系统架构方面的东西：
比如开发模式，软件分层与组件复用等。这些感觉都要经过一段时间的积累而成。
Top25楼 zhaoyifei1 (一非)
我感觉ejb为了让你全神贯注的关注你的客户的需求，而不是关注程序！！程序员的精力毕竟有限，如果想更好的应对将来的大规模开发，你就必须更加关注需求，关注模式，而不是关注程序的安排
Top26楼 chashui (茶水)
开始听课
Top27楼 thumb3344 (祖国啊,我只是一个摆地摊的!)
up
Top28楼 Orchid (orchidflower)
可能过几年才能体现出优势来吧，等容器更加成熟稳定，速度更加快，不在被大家指责的时候，EJB就会体现出它在分布式方面的优势来。所以我觉得它的前景也许不错，现在……
Top29楼 VVV_lucky (*太阳*)
扇子出来说两句吧。
Top30楼 Schlemiel (维特根斯坦的扇子)
在我看来EJB的集群能力是无与伦比的。如果需要应用服务器级的集群，EJB几乎是唯一可选的方案。当然集群本身就很有讲究，如果在性能瓶颈是在web层或者数据库层（实际情况往往是这样），应用服务器的集群就毫无意义。application clustering，我认为是选择EJB的第一理由。
大家请继续。我相信很多人做过EJB开发，应该可以从实践经验中找到一些EJB的长处。
Top31楼 samue (下弦月)
其实EJB本没有什么好处，用的人多了，便好象有了很多好处
呵呵
Top32楼 jacklondon (jacklondon)
EJB 是用在分布式环境下面，如果有多个 server 多个 database 才用。只有一个 server 一个 database 没有必要用，这是很多 EJB 经典书籍中都讲的，可惜很多人都不注意。
一个 server 一个 database 完全没有必要用 EJB.
实际上在 ASP/ASP.net 编程中，多个 database 情况由 database 自己做数据同步，主流数据库都能做。多个 server 由操作系统做负载平衡，这个需要 Windows 2000 advance server 或者 Redhat enterprise server 。基本上，对于编程者来说，只要安装正常一个 server 一个 database写法写程序，不用懂太多东西。我比较看好这种做法。
Top33楼 jacklondon (jacklondon)
实际上，如果没有分布式的需求，用 jsp/servlet 开发即可。以后需要改成分布式，原来的代码又不是不能用。大部分代码都可以 copy , 做少量 modify 即可。
现在很多人在一个 server 一个 database 下面用 ejb, 不懂是为什么，乖乖！！
Top34楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
首先copy and modify的做法是绝对不可取的。你可以根本不用问为什么，重复代码是万恶之源，哪怕你找出一千个理由说服自己“这次的重复代码不会出问题”，最后你仍然会被重复代码狠咬一口。有些事情不一定非要尝试的。
数据库的集群应该由数据库来做，这一点我同意。但是“多个 server 由操作系统做负载平衡”，我可能就要持保留态度。最简单的例子：如果你的business service组件是有状态的，哪个操作系统能在不同的进程之间保证同一组件的状态一致？不用懂太多东西的话，写出来的程序也不会有太多用处，这不是观点，是经验。
Top35楼 leshui (大象无形)(有物混成，先天地生)
关键要大型应用的时候才能看出效果
小的东西没又必要用ejb
Top36楼 shmiluwei (宝宝最爱)
斑竹的题目我觉得很恐怖，好像大家都没有机会锻炼脑子，：），
我觉得EJB是面向需求的。
Top37楼 Schlemiel (维特根斯坦的扇子)
to shmiluwei(井底蛙)：
“EJB是面向需求的”。你觉得这句话说了跟没说有什么区别呢？我觉得没有。纯粹就是一句不痛不痒的废话，而且跟我的问题根本不搭界。EJB到底好不好？好在哪里？我想没人能从你这句话里看出答案。你还不如说“道可道非常道”呢。
从你这个答案，我倒觉得你的确有点缺乏锻炼脑子的机会。
Top38楼 blue999star (星星要挣钱，养老婆)
如果表示层（界面）我不用jsp，不在浏览器里操作，而选用application 也就是swing那套东西，使用java web start。那么是不是ejb也将成为必须的选择？？？楼主及各位高手能不能回应一下！
Top39楼 Schlemiel (维特根斯坦的扇子)
to blue999star(星星要挣钱，养老婆)：
其实也不一定。我前面说过了，应用服务器的集群是使用EJB的第一理由。以前曾经还有两个选择EJB的重要理由：容器管理的事务（CMT）和——像你一样——分布式体系结构。但是现在我们已经发现，这两个理由不能成为使用EJB的充分条件。我们已经有了轻量级容器，例如Spring和PicoContainer，那么我们就可以给POJO加上横切的infrastructures，例如CMT。Spring可以提供AOP能力，再加上JOTM，我们同样可以实现分布式的CMT。
你需要的分布式能力也是一样。EJB提供了RMI远程通信的便利能力，所以很多时候我们把EJB作为分布式系统的第一诉求。但是现在提供RPC的方式也很多，譬如Hessian（http://www.caucho.com/hessian/）或者Axis（http://ws.apache.org/axis/）。我有个朋友一直在用Hessian做RPC，通过WebStart提供界面，开发方便，效率也高，而且对server没有特殊要求。如果用session bean提供RPC服务的话，你至少得把RMI端口打开吧。
Top40楼 huhuchong (糊糊虫*努力学习中)
MDB,JMS可以完成很多一般很难搞定的事
Top41楼 Schlemiel (维特根斯坦的扇子)
对。MDB是一个好例子。
Top42楼 huhuchong (糊糊虫*努力学习中)
我参与一个大型的J2EE项目,我想问问如何设计和优化CMP,这东西真的很慢,
而且设计项目的人也很牛B,J2EE模式和EJB模式都运用的很不错,SessionBean和CMP用的也是本地接口,但操作数据就是很慢.....
Top43楼 ai92 (抵制日货^o^)
老师让我给他做一个用户登录界面
我说我用JSP 给你搞定吧
老师不同意，让我用EJB ，结果到现在我还在东搞西搞，郁闷。
不同意楼主的--〉重复代码是万恶之源
坚决反对，什么事物都是有两面性的，没有什么东西是绝对坏的，重复代码在一定的情况下应该就是代码重用，这是软件工程，Java的继承、重载等等所提倡的。
Top44楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子) ,
你不要断章取义。
我说的“以后需要改成分布式，原来的代码又不是不能用。大部分代码都可以 copy , 做少量 modify 即可”，
意思是 jsp + javabean 代码如果需要升级成 EJB + javabean, 大部分代码还是可以接着用的，特别是 javabean 中的代码，略作修改即可。
Top45楼 blue999star (星星要挣钱，养老婆)
to Schlemiel(维特根斯坦的扇子)
首先感谢你的提供的信息。虽然我问的离你的题目有点远。希望讨论能增加大家对ejb的更深认识。第一感觉，我以为你会引用Hibernator来说明问题。没想到你提到Spring、PicoContainer等（我对这些基本上没有概念，刚搜了一下看了看，见笑了。）。一个问题总是有很多的解决方案，我们希望选择最好的，最适合自己的。从构架一个系统 或者说拉单子角度讲，不可能说现招一批程序员或者花一段时间培训，更不可能给客户去讲Spring或Hessian如何可以替代ejb更好的处理事务问题、分布式问题。这似乎是选择ejb的问题了。
从某种角度讲，选择了说明他对自己目前状况有一定的选择优势，不知道会不会遗害无穷……
Top46楼 huhuchong (糊糊虫*努力学习中)
同意楼主的--〉重复代码是万恶之源
重复代码加重后期维护的工作量,严重影响扩充性.功能类似的代码完全可以封装成接口供其他类调用.设计模式的运用很大程度上就是为了避免代码重复,降低偶合.要不项目的整体架构设计也不会占最大的比重.偶比较菜,只是说说自己的一些观点看法.请高手指点
Top47楼 jacklondon (jacklondon)
建议 Schlemiel(维特根斯坦的扇子) 看看 ASP/ASP.NET 的书籍，看看里面的多服务器集群中关于 session 的部分。
其实很多人不愿意用 EJB 不是说 EJB 不能做什么，而是它没有封装好。一个好的工具包应该是好用的。
使用 EJB 应该看情况。
EJB 与 DCOM 的竞争，最后可能像 ANSI C++ 与 VB 的竞争。因为大多数项目用简单工具即可完成，所以 VB 比 ANSI C++ 流行，DCOM 比 EJB 使用者更多。
另一种类似的比较是, Unix 很多功能比 Windows 强，但是因为不好用，结果Windows 的市场份额占了大部分。现在 asp 远比 jsp 流行也说明了这一点：对于论坛，OA 之类的B/S程序，用 asp 足够了，所以它流行。
EJB 最后的出路是，在更复杂的情况下一统天下，而大多数中小项目中，EJB是失败者。因为大多数中小项目的程序员占了总体程序员数量的大多数，结果使用 EJB 的人远不如 jsp,而用jsp 的远不如 asp.
Top48楼 ooprogramer (混子)
我也不知道ejb是什么东西，但听我同事说它是垃圾。
Top49楼 jacklondon (jacklondon)
推荐大家看 《EJB编程指南》(Rahim Adatia, Faiz Arni, Kyle Gabhart)，里面关于什么时候用 EJB 有很好的见解。
服务器集群中的 session 问题，建议大家看 JBoss 或者 Weblogic 的文档。基本上变成的时候不用考虑它，这是一个配置问题。
ASP.NET 我建议大家看 《ASP.NET 技术内幕》( Stephen Walther )，里面关于服务器集群中的 session 问题有非常妙的讲解。
另外，建议大家同时学习集中技术，这样你才能知道，每种技术的优点，缺点。只学一种，永远达不到这种境界。
Top50楼 huhuchong (糊糊虫*努力学习中)
jacklondon(jacklondon) 你说的对啊 的确许多中小型项目没必要用的EJB,完全可以用M$.NET studio进行快速开发,后期的维护也比较简单,也不需要扩展什么功能.
但是...我想大家知道软件业比较有钱的几个主 应该是电信,银行,金融,政府,项目一般投入很大,后期维护升级工作量也很大,如果没有一个优秀的架构平台(比如J2EE),和良好的项目架构设计,我想这样项目到后期维护的时候一定让人痛苦欲绝....
我想学好J2EE还是很不错的选择,上升的空间也比较大,可学的东西很多....
个人观点,不代表广大群众...呵呵
Top51楼 Schlemiel (维特根斯坦的扇子)
to ai92(抵制日货^o^) ：
不要说什么“什么事物都是有两面性的”。没错，什么事情都不绝对，什么事情都会有例外的时候，但是有些事情你没资格去探讨它的例外。就好象牛顿力学也有不适用的时候，但你骑着自行车就没资格去考虑牛顿力学的例外。有些东西是几十年、无数人的经验积累下来的，比如重复代码是万恶之源，你没必要也没资格去质疑它，因为你要么照着这个经验去做，要么撞得头破血流。不信你就可以自己去尝试。
代码重用、继承到底是鼓励重复代码还是极力避免重复代码？重载和重复代码有什么关系？麻烦你先去补习一下Java入门课程，这个帖子里的内容可能暂时还不适合你参与。
to jacklondon(jacklondon)：
没记错的话我记得你曾经在另一个帖子里说“Windows程序员比Unix/Linux程序员多”，现在你又说“大多数中小项目的程序员占了总体程序员数量的大多数”。既然如此我们就没什么好讨论的了。逻辑学告诉我，如果你接受一个矛盾式（也就是说，把一件假的事当成真的），你就可以从中推出任意结论。
Top52楼 ccjerk (岚)
EJB 是什么咚咚
欧不认识他 他也不认识偶
来学习了
顺便 up
Top53楼 jacklondon (jacklondon)
忘了说了, tomcat 可以支持服务器集群， session 可以自动复制，不过性能不够好。可以参考 tomcat 文档。没有必要一定要 EJB 才能做分布式，呵呵。
Top54楼 huhuchong (糊糊虫*努力学习中)
回去了~~~顶一下~~~~明天接着看~~~~~
Top55楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子) ,
"Windows程序员比Unix/Linux程序员多","大多数中小项目的程序员占了总体程序员数量的大多数",有什么错么？对不起，我弱智，我看不出有什么问题。
如果你一定要说Unix/Linux程序员比Windows程序员多，那也由你。招聘网站上面 windows 程序员的职位可比Unix/Linux多。
好像大多数程序员都在做中小项目，如果你一定要说，超过 50% 的程序员在做大项目，那也由你。只是这可能吗？
Top56楼 usabcd (9号公路上的3名共军)
你还别说，搞软件的，好像都是有点个性的哦。
本来技术上的东东，争着争着，一不留神就激动了。
Schlemiel(维特根斯坦的扇子)同志说的重复代码是"万恶之源" 偶举双手赞成并深有体会。
但是 jacklondon(jacklondon) 同志说的 搞中小型项目的人多些这个恐怕也是事实吧。
Top57楼 fengjing1108 (枫敬)
看了整版
不懂
Top58楼 bon_jovi (西门疯雪)
很久前发过回复，现在回来看看，讨论好热闹。
扇兄说的对，重复代码绝对是万恶之源，当你维护自己的代码的时候就会感觉到了。
推荐martin flower的《refactor》。他里面说的很清楚了，那些codes是bad smell。
另外我们还是回到正题，讨论ejb吧，别又扯到.net和java之争了。
Top59楼 Schlemiel (维特根斯坦的扇子)
我自己总结了一下，使用EJB的正当理由：
提供应用层组件的集群
提供与CORBA客户端的互操作
消费JMS异步消息
可以考虑使用EJB的理由：
提供多线程解决方案
基于角色的访问权限控制
熟悉EJB架构
使用EJB的可疑理由：
清晰的多层体系结构
entity bean的O/R mapping能力
基于RPC的分布式体系结构
容器管理的基础设施（例如CMT）
看看有什么想法？
Top60楼 ai92 (抵制日货^o^)
哈哈，犯老毛病了，把“重复代码”理解成了“代码重用”
（就像以前犯的毛病：人家说过了ＳＣＪＰ了，问下一步干什么，结果我上来就指点人家怎样才能过ＳＣＪＰ！！）哈哈，自嘲一下，缓解这里的火药味
大家不必为了ＥＪＢ有什么好处来争来争去，我也不认为这个能锻炼脑子，但是觉得锻炼大家的打字功夫和互相讽刺的刁钻～～～
ＥＪＢ有什么好处？？这和当年热极一时的话题“ｊａｖａ好还是Ｃ＋＋好？”有什么区别？？本质上不是一样吗？？
建议楼主不要在讨论这样无聊的话题：看得出来你对EJB非常看好，那你还在这里冠上“锻炼脑子”的堂皇名义争什么？为了让别人说服你不用EJB，还是要教育别人“你们不懂ＥＪＢ＂？？！！
看得出楼主水平不低，有这个功夫，不如发几个实用的技术贴，让我们这些不适合讨论这种问题的人补补课？？？！！！！
Top61楼 ai92 (抵制日货^o^)
哈哈，犯老毛病了，把“重复代码”理解成了“代码重用”
（就像以前犯的毛病：人家说过了ＳＣＪＰ了，问下一步干什么，结果我上来就指点人家怎样才能过ＳＣＪＰ！！）哈哈，自嘲一下，缓解这里的火药味
大家不必为了ＥＪＢ有什么好处来争来争去，我也不认为这个能锻炼脑子，但是觉得锻炼大家的打字功夫和互相讽刺的刁钻～～～
ＥＪＢ有什么好处？？这和当年热极一时的话题“ｊａｖａ好还是Ｃ＋＋好？”有什么区别？？本质上不是一样吗？？
建议楼主不要在讨论这样无聊的话题：看得出来你对EJB非常看好，那你还在这里冠上“锻炼脑子”的堂皇名义争什么？为了让别人说服你不用EJB，还是要教育别人“你们不懂ＥＪＢ＂？？！！
看得出楼主水平不低，有这个功夫，不如发几个实用的技术贴，让我们这些不适合讨论这种问题的人补补课？？？！！！！
Top62楼 Schlemiel (维特根斯坦的扇子)
说错了，我对EJB一点都不看好，我一贯认为90%的情况下使用EJB是误用，我推荐的是轻量级的方案。
发这个帖子的初衷就是让大家锻炼一下脑子，也给我自己锻炼一下脑子。对于一个你不喜欢的技术，你要学会去认识它的长处。对于你喜欢的技术，你要学会去认识它的不足。至于到底能不能达到锻炼的效果，那就是每个人自己的问题了，你要是觉得无聊就请不要参与。
Top63楼 Schlemiel (维特根斯坦的扇子)
另外，我并不认为“Java好还是C++好”是个无聊的话题，只不过很多人没有充分了解比较的双方（甚至是任何一方都不了解），就开始凭着道听途说甚至是主观臆测来发表评论。无聊的是这种不负责任的评论，而不是话题本身。你可以去看看那本《对象揭秘》，那本书的核心就是语言（C++、Java和Eiffel）的比较，我想那不是一本无聊的书。
这个话题也是一样。EJB有什么好处？有什么不足？是否使用EJB？如何使用？这是J2EE架构师面对一个新项目时要解决的第一个大问题，怎么会是无聊的话题？同样，是某些参与者显得有点无聊。譬如说，开口就说“EJB是骗钱的把戏”，莫非全世界那么多架构师都是白痴？这就是不负责任的评论方式，不仅对别人不负责，更是对自己不负责。
Top64楼 ufc (为棋)
我认为EJB好处是继承了JAVA语言面向对象设计和网络语言的好处，同时又实现了CORBA的接口，一个使用EJB实现的企业级应用实现软件组件化，使开发成流水化，集中实现降低软件生产成本，提高软件的价值。但对小型应用，个人认为除了一点设计模式变化带来的好处，无它效果！呵呵,一家之辞.
Top65楼 ufc (为棋)
了解CORBA就知道EJB的初衷，了解CICS就知道了容器的初衷，了解MQ就知道JMS的初衷，了解SNA的Session也就知道J2EE中Session含义,SUN做了IBM没法做到的让这些概述通俗化、产品普及化，相反他们把它理论化，复杂化。其实在学术上对这些东西的研究，IBM可能是领跑者，别人是在默默的分享她的成果。我并对IBM有额外的崇拜，只是在我每看到一个新东西时就发现IBM很早就提出并使用了，只不过是在大家记忆已遗忘的地方,IBM的东西就像伊斯兰的美女，虽然美丽但被面纱给遮住了，我也只是出于好奇心才去揭面纱的.呵呵,一家之辞.
Top66楼 rocshaw (太阳鸟(抵制日货))
我想，它的好处就是标准，当需要系统升级或更换开发商时不会太麻烦
Top67楼 usabcd (9号公路上的3名共军)
to Schlemiel(维特根斯坦的扇子)
看了你的总结，还是有些疑惑：
使用EJB的正当理由：
提供应用层组件的集群
--(这个也许是真正的理由，但这个特色可能被它的低效率所抵消)
提供与CORBA客户端的互操作（这个不是很了解，不过好像没看到多少人是因为这个而使用EJB的）
消费JMS异步消息 （这个我个人觉得是一个不错的原因，因为实际中经常有这样的需求）
可以考虑使用EJB的理由：
提供多线程解决方案
－－（多线程？这个不是非要EJB才能实现吧）
基于角色的访问权限控制
－－（这个也有点牵强，任何一个权限控制系统都会考虑按角色来控制吧，不能算做EJB的特色）
熟悉EJB架构
－－（这个不能算做理由，我们使用某种工具的原因应该是为了解决或更好的解决问题，
而不是熟悉解决问题的工具本身）
使用EJB的可疑理由：
清晰的多层体系结构
entity bean的O/R mapping能力
基于RPC的分布式体系结构
容器管理的基础设施（例如CMT）
－－（这个基本同意，不过好像大多数的EJB项目也就恰恰仅用到这几个功能，很多EJB
项目连分布式的功能都没用到）
Top68楼 Schlemiel (维特根斯坦的扇子)
RMI/IIOP和CORBA的交互很简单，所以用EJB提供与CORBA的互操作其实是一个不错的办法。同样，EJB容器提供的多线程和访问控制也是使用简单，用其他方式也可以实现，但EJB提供了现成的东西，所以这两个我觉得是“可以考虑”的理由。
熟悉EJB其实是一个很可以考虑的理由。如果团队只熟悉EJB，对轻量级方案一无所知，项目时间又比较紧，用EJB凑合一个项目我觉得也是完全可行的，虽然有点不那么优雅。
Top69楼 zcjl ()
^_^
扇子牛人应该说清楚
你这个帖子是提起一个话题给大家讨论
让大家借这个由头去思考ejb到底有些什么好处和缺点
也就是说，这个帖子的意义是在思考ejb的优缺点的过程中得到体现的
可是帖子里的好多人却把这儿当作给ejb下定论的地方了
所以常常会冒出“ejb是垃圾”的说法
我认为，如果有机会的话，你可以就这个话题去和robbin、banq等讨论一番
让我等菜鸟也看看哪些是我们平时没能细心去思考的
最后，我还是认为你是个有技术、有思想的牛人
而不是靠贬低菜鸟来获得些许“虚荣”的小人
但是如果你真的有心给这个常来的坛子提高一点讨论的品味的话
也许你应该改换一种语气和姿态，加上一点适当的引导
否则，恐怕只会是事与愿违，大家吵得不亦乐乎，却什么价值都没有
ps：因为迄今为止所做的项目都小得可怜，所以对ejb也只是耳闻而已，我就不用在这里显露菜鸟风采了
：）
Top70楼 Schlemiel (维特根斯坦的扇子)
有道理。
这个话题，我私下跟robbin和banq讨论过好久了，从去年聊到今年。最近在做个presentation，需要总结一下，所以又想起来。另一方面也是想看看还能不能从这里得到更多的启示。
Top71楼 zcjl ()
同意楼上usabcd(分不在少，有分必接) 的观点
扇子对使用ejb的理由的一些总结有点牵强
窃以为，之所以很多人吵吵嚷嚷着使用ejb，只是因为他们根本就不了解系统方案设计，也不了解ejb，只是听得多了而已。当然，还可能是基于客户的压力
之所以得出这样的结论，是因为我们也曾犯过这样的错
在刚开始对jsp都还不了解的时候，竟然都摩拳擦掌准备上ejb
一群刚初学java/jsp的人就开始深入研究j2ee架构的实现，动则讨论设计模式的优劣，这就是我们毕业设计时做的蠢事
后来了解稍多一点时，才明白现阶段根本就用不上ejb这样的东东，改为学习struts的应用了
Top72楼 javer6 (孤舟万里)
哈哈，来晚了！很久没上来了，今天看到这个贴子，而且是扇子发的，我更要参与了！
对于扇子提到的重复代码是万恶之源！这个观点我百分之百赞同阿！真的是血泪的教训阿！！
如果你的代码出现这样的重复代码，那只能说明一个问题，你的设计又问题。
上次关于instanceof的争论，我回去重新设计了一边，感觉完全可以避免，抽象的合理是设计的关键！如果你的系统两个可以new出来的类互相关联，那么你的设计肯定存在问题！感谢扇子，感谢！
至于EJB，不是很熟，而且听说他的效率问题，更是不敢使用它！如果客户看到它的点击迟迟不见反映，你的所有努力立刻over，客户才不管你的设计多么OO。
Top73楼 holder (明年俺就毕业了)
又学了点东西，多谢多谢。
Top74楼 Schlemiel (维特根斯坦的扇子)
呵呵，javer6(孤舟万里)怎么样，我没骗你吧？有些时候衡量一个设计方案不一定要硬去分析的，设计做得久了，常常就可以靠审美的眼光来衡量。为什么我们经常把好的设计称为“优雅”，原因就在这里：好的设计有一种美感，因为简洁就是美；具有美感的设计往往在性能、维护性等方面也有优势。所以有时你不要让一些细节蒙住你的眼睛，用审美的眼光去看待自己的设计，在那些让你感觉不到美感的地方，往往可以找到设计的缺陷。现在AOP很流行，也就是因为一些OO设计细看之下毫无问题，但整体看起来就是缺乏美感，所以才引出了这么一个颇具革命性的概念。
Top75楼 javer6 (孤舟万里)
自己多看看人家的设计，看看他们的代码！自己好好想想，好好想想。
不禁拍案叫绝！
奶奶的！我怎么没想到这样设计呢？
差距而已，自己努力中！
附：1）reflect包对于较复杂的设计确实是一种良药。2）为了抽象而抽象，不好！接口的分离，业务逻辑单一很重要。3）只看到表面而没有看到本质是导致设计失败的主要原因！
Top76楼 panpan221 (我是来学习的!)
关注
Top77楼 totodo (土豆仙)
我最近病了。555555
要加强锻炼身体了，处于亚健康的兄弟们！！
说几点招人非议的话吧：）
EJB是期望代码复用的，重构架的，有一整套解决方案的，规范的。
主要优点也在这里了。 即便不考虑它的分布式，我们可能也考虑使用EJB..（如果在传统的JSP+Bean的年代）
现在就不一样了，现在我们有Spring,Hibernate,Struts,还有SOAP,AXIS等等的
即便不借助EJB这样的体系，我们也可以做RMI，也可以构架一个低偶合的，分层的系统。也可以自己写粗粒度的业务组件。 甚至，我们可能都不需要上面的那些Framework.如果够牛气的话。
所以，关键 还是要看我们 “怎么使用现有的技术！”
Top78楼 feifeirao (人渣)
暂时还不懂EJB
这是一个好话题.
听说EJB有难度
Top79楼 plato (天天)
第1，ejb容器帮助实现了安全，在ejb基础上可以很方便地定义针对每个business方法的认证。
第2，ejb容器帮助管理事务，开发者只要在配置文件里设定Required,NotSupport等属性。
第3，j2ee实现了全局事务管理。
第4，ejb容器帮助实现了对象持久性（虽然备受争议），Hibernate等可以看作很不错的补充
第5，j2ee帮助实现了Cache, 连接池等。你自己开发会有weblogic开发的效率高吗，你懂得如何避免死锁么？
综上所术，j2ee提供了一个很好的框架，j2ee server厂商提供现有的成熟技术基础上的各种服务。
Top80楼 filippo1980 (管药师★(加班中......))
复杂问题简单化,简单问题合理化! 是我的宗旨.
只要能合理便捷的解决问题,用什么方案是无所谓的!
Top81楼 cwwwj (392-387-44-17-377)
俺不懂什么是EJB不敢瞎说
Top82楼 appleangle (苹果熟了)
学习
Top83楼 Schlemiel (维特根斯坦的扇子)
to plato(天天)：
照我现在的经验来看，你说的几点使用EJB的理由都可以商榷。
>>第1，ejb容器帮助实现了安全，在ejb基础上可以很方便地定义针对每个business方法的认证。
>>第2，ejb容器帮助管理事务，开发者只要在配置文件里设定Required,NotSupport等属性。
这两件其实是一回事：声明性infrastructure。实际上，只要有一个容器来管理组件的创建，我们总可以拦截组件的方法调用，于是总可以提供声明性事务或者声明性安全认证。现在Spring容器已经可以为Hibernate和JDBC提供声明性事务，结合JOTM甚至可以提供声明性分布式事务。安全性的问题也是一样，用Spring AOP拦截方法调用，结合JAAS就可以提供声明性访问控制。
>>第3，j2ee实现了全局事务管理。
所谓“全局事务管理”是什么概念，想请你介绍一下。
>>第4，ejb容器帮助实现了对象持久性（虽然备受争议），Hibernate等可以看作很不错的补充
entity bean是我见过的O/R mapping中最差的一个。它对实体的描述能力太弱（实际上不支持继承），对实体对象的限制太多（要求继承接口），查询能力太弱（不支持动态查询，更不支持非对象查询）。现在就连Sun的人都已经不推荐用entity bean了，他们用JDO。在O/R mapping这里，Hibernate和Castor都比entity bean要好。
>>第5，j2ee帮助实现了Cache, 连接池等。你自己开发会有weblogic开发的效率高吗，你懂得如何避免死锁么？
cache有现成的框架可以用，例如OSCache和EHCache。如果是使用Hibernate，EHCache就只需要配置一下，连一行代码都不用写。至于连接池，我想这跟EJB不搭界，J2EE application server上的任何一个应用程序（不管是POJO还是EJB）都可以利用服务器提供的连接池。
不过，如果要抛开EJB的同时获得上面说的这些功能，你需要了解更多的open source项目，需要做更多的集成和尝试。如果这方面的成本对于你是不可接受的，那么EJB仍然是一个很好的选择。
Top84楼 game0ver12345 (sfsfdsfdsdfsf)
回复人： filippo1980(管药师★我爱刘蓓丽) ( ) 信誉：122 2004-04-25 10:56:00 得分:0
复杂问题简单化,简单问题合理化! 是我的宗旨.
只要能合理便捷的解决问题,用什么方案是无所谓的!
=====================================================
能简单化的问题是伪复杂
Top85楼 javer6 (孤舟万里)
Schlemiel(维特根斯坦的扇子) :
看了这么多争论，我也想说两句。特别是看了扇子精彩的“答辩“，感觉很是差距呢！：（
不过看的同时，我似乎发现了一个特点：
就是每次当有人列出EJB容器一大堆已经集成好的特点时，扇子都一一引用某些更好的开源project作了回应，扇子，或许你也应该注意到，现在有这样的产品，他能够将你所列举的每一个poreject整合到一起作为一个集成开发系统提供给基于整套稳定框架迅速搭建稳定的web系统码？EJB正是提供了这样一套集成，虽然他所提供的每一项功能并不都是很成功，但这已经让他足够获得广大开发者的喜好。试想，并不是很多人都能迅速掌握每一个开元项目并能将之整合到自己的web app中得。EJB容器只是早于一步做到了这点，虽然源于开发时间差而造成诸多功能不完善（譬如如果hibernate早于JBoss出现，Jboss还会用Entity bean马还是很大疑问），但是，对于很多对诸如j2ee相关概念懂一半的人已经足够了。
现在，真得很希望，能有人整合所有优秀项目而提供一套框架或者更成熟的产品给我们用啊！！对于，众多的项目，我应付有点吃力哦。工作又忙，而客户提出的开始周期又短，给我一个Jboss,我当然是用它了！
Top86楼 yeshucheng (叶澍成★七哥---原来自己差距还很大)
在某些网站完全可以不用它的，这个完全要看你的设计跟工程的大小。
当然有些用到了，也是个噱头（容易骗客户的钱）不过也得会就是了：）
Top87楼 TyroneChan (油亮脖子金黃腳)
已經收藏了，是個有討論價值的貼子，現在忙，等一下回頭再來
Top88楼 Schlemiel (维特根斯坦的扇子)
to javer6(孤舟万里)：
所以我前面说过，“熟悉EJB架构”绝对可以成为选择EJB的一个好理由。EJB的缺点并不是像你说的“功能不完善”，而是在于它一次性提供了太多的东西。EJB是一个“全有或全无”的选择，你不能说“我只要声明性事务，不要其他”，不行的，即使你只用其中任何一项，都必须承担整个EJB架构的庞大。轻量级解决方案的好处在于你可以选择自己真正需要的，不用为不需要的东西买单。但是就像你说的，选择和整合的过程也需要成本，很多公司确实做不到这一点，那么对于他们来说，继续沿用EJB的方案也是一种不错的选择。
当然另一种选择是找我给他们做个培训。
Top89楼 lynx1111 (任我行:一个PLMM看着就兴奋的男人)
Top90楼 zcjl ()
而是在于它一次性提供了太多的东西。EJB是一个“全有或全无”的选择
－－－－－－－－－－－－－－－－－－
这大概就是为什么大多数用过ejb的人都说它粗笨的原因吧？
Top91楼 beming (Aming)
看使用环境了，有些开发要求确实使用ejb好。
Top92楼 huhuchong (糊糊虫*努力学习中)
使用EJB再陪上集成开发环境的IDE工具WSAD,开发EJB的项目还是很轻松的,很多东西都给你配置好了,操作起来也很方便.
开源的一些东东我很有兴趣,对开源将来的发展很有信心,可现在还没时间去学,有时间一定多多学习一下,向高手们多多请教.
Top93楼 huhuchong (糊糊虫*努力学习中)
我有个不情之请
不知道"扇子老大"可否将您认为很有价值的开源文档资料(中英文均可)打包一份给我呢....
不甚感激....
Top94楼 julian_zzx (竹十一)
据说EJB真的很多很多银子啊！
我想这就是好处了
Top95楼 jacklondon (jacklondon)
Anders Hejlsberg 说，“我坚信简单就是美”
极限编程说，“用最简单的方法来解决问题”
爱因斯坦说，“用最简单的方法来解决问题，但不要过度简单”
Top96楼 javer6 (孤舟万里)
Schlemiel(维特根斯坦的扇子)
〉〉当然另一种选择是找我给他们做个培训。
要是我是老大，肯定请你给我们上培训。可惜。。。。最近我们单位上一个项目亏损巨大,费用极度压缩（秘密，说漏嘴）.哎！
Top97楼 joincsdn (云)
没用过EJB！
好好学习各位高人的经验！
Top98楼 missRainbowAgain (godness)
刚想学EJB,不懂，学习
Top99楼 yujiebo025 (独舞黄纱)
路过，学习！！！
Top100楼 xuu27 (乐者为王(xuu27))
mark
Top101楼 xfanghua (红尘摆渡人)
评论EJB的优缺点最还还是和对应的技术相比较
ejb不能做好的，别的对应技术能做好吗？
或许各有所长罢了
Top102楼 xue_sharp (龌龊猥琐并且BT男)
我们现在系统的设计方案就是STRUTS + SESSION BEAN + IBATIS,用ejb也是我确定的,但是只使用的无状态会话bean.从技术层面上的分析我就不再多说了大家个有各的看法.但是从程序供应商的角度来说,我封装的业务逻辑我不知道什么比发布一个EJB包和一份部署文档更清楚直观.
至于开发调试中EJB的不便,我们是这样做的,不把业务逻辑放在bean类中,而是普通的java类.当开发调试结束的时候,再打包成EJB发布
Top103楼 xue_sharp (龌龊猥琐并且BT男)
如果你不是做整个项目,而是做其中的一部分逻辑接口供别人调用.ejb(SESSION BEAN)是最标准也是最快捷的部署以及配置RPC方案.至少调用的人不用去学习别的调用方式
Top104楼 xue_sharp (龌龊猥琐并且BT男)
我想一个设计分析作的都很明确的项目,业务逻,VO,DAO都分层的话,切换到EJB方案并不需要太大的改动.
Top105楼 yeshucheng (叶澍成★七哥---原来自己差距还很大)
目前我看过的session bean中用到的有状态的很少。ejb的横向面给人的感觉比较大气，不过在某些层次有点过多的冗余（个人感觉），在用到vo的同时有时还是感觉到了ejb体现的一个比较明显的特点---粗粒度的考虑，对于这个我想对于那些真正搞软件工程的来说确实是起到一个事半功倍的效果，一处修改处处得益。
但是在调用ejb的同时也考虑一个时间的消耗，虽说有个单例类（singleton），但是我没有真正感受到它的优越性的存在。。。。
或许这个还有待真正的实践来推理
Top106楼 masakiyy (我的老婆是岚岚)
好处一：烦；
好处二：难。
我接触得到项目没有一个真正需要使用EJB的，那玩意儿做出来可以多骗客户一点钱，呵呵。
Top107楼 TIANHEI (示其)
EJB是不是很高很深那？
Top108楼 minghuitian (明月)
up
Top109楼 steedhorse (晨星)
刚刚看到一篇文章。
http://www.jdon.com/artichect/whyEJB.htm
Top110楼 zkjbeyond (jigi)
吵醒我了。
不知道大家开发过rmi没有。EJB是基于rmi的，都算远程对象调用。也可以说是分布式系统，你的系统没必要有远程对象调用，没必要分布式，那根本没有必要。毕竟速度是很慢的，设计要求也是很高的。
（我最讨厌别人在没开发过ejb的情况下说ejb慢了，你要选择ejb你就的知道远程调用的速度，你在一个jvm里，当然快了，另外，EJB的设计绝对要求高手级的任务设计，对面向对象、面向组件有足够的经验。就你照着书弄了一个那能叫EJB吗？？？）
Top111楼 zkjbeyond (jigi)
假如一电信客户，要增加一新电话套餐业务。（我在unix服务器上）
IE上可以注册，手机可以注册，jsf(java\swing)程序可以调用。
那你们说业务逻辑要放哪儿，map o/r 怎么映射。
不但要用ejb，也要用扇子说的集群。
Top112楼 huzhigang (hu)
不知道为什么在每个论坛都有这种讨论，或是为什么要使用ejb或是为什么要学习ejb。然后无论是什么人怎么答复，大抵都是楼主反驳指出ejb其实根本不行。令我感到奇观的是既然如此还讨论什么呢？既然你认为ejb如此不堪又何必开始一个这样的讨论。个人认为，这其实表明呢楼主本身的矛盾：觉得ejb不好，想放弃使用或学习ejb。但又担心ejb依然发展从而导致自己在技术上的偏差。所以想看看别人是怎么说得，想看看别人能不能说服自己继续使用ejb。想看看到底有多少人是支持ejb，多少人是反对ejb，从而判断一下自己的结论。我真不知道这种讨论有什么意义？很多人不使用jsp来作为表示层技术，而使用velocity等替代技术。可确没几个人来讨论为什么要使用jsp的问题？为什么？其实从某个方面也表示了ejb现在确实影响如此的大，以至于但你不想使用的时候会如此的没有自信和担忧。担忧自己不使用ejb被淘汰，确又担忧使用ejb而ejb本身被淘汰？从纯粹技术上来说，ejb确实有很多的问题，因为本身ejb设计的前提是用了解决最麻烦最大问题的，所以为了解决这些复杂的问题，ejb的设计人员不得不在设计的时候考虑了很多我们可能根本不用的功能。我觉得在实际的使用种出现这些问题根本就是正常的。如果是这样，你不要就完了呗。ejb适合的领域是肯定存在的，而ejb作为j2ee的规范之一不被支持的可能性和j2ee不被支持的可能性几乎相同。作为一个j2ee程序员，是应该清晰的学习ejb和他的使用前提的。而不是在这里讨论为什么要使用ejb。坦率的说，这和讨论为什么要使用j2ee而不使用.net一样的没意义！
Top113楼 zkjbeyond (jigi)
楼上说.net。我接触的很多asp.net程序员连.net怎么实现分布式也不清楚，很在那老和j2ee比较，sb一堆。
Top114楼 zkjbeyond (jigi)
很多程序员用asp.net开发个破网站就说.net如何开发快了。效率高了。还说ejb多么复杂了。
可惜中国很少有项目用到企业级分布式系统。悲哀
Top115楼 Schlemiel (维特根斯坦的扇子)
to huzhigang(hu)：
>>这其实表明呢楼主本身的矛盾：觉得ejb不好，想放弃使用或学习ejb。但又担心ejb依然发展从而导致自己在技术上的偏差。所以想看看别人是怎么说得，想看看别人能不能说服自己继续使用ejb。想看看到底有多少人是支持ejb，多少人是反对ejb，从而判断一下自己的结论。
我经常说，你要在一个论坛开口说话之前，应该先潜水观察一段时间，不然开口就很容易闹笑话。我会有这么有趣的“矛盾”？你不妨先看看上下的回复，看看CSDNers对EJB的认识普遍有多么肤浅多么片面。我发这个帖子目的就是给这里的人一个锻炼的机会，一个整理思路的机会。
>>从纯粹技术上来说，ejb确实有很多的问题，因为本身ejb设计的前提是用了解决最麻烦最大问题的，所以为了解决这些复杂的问题，ejb的设计人员不得不在设计的时候考虑了很多我们可能根本不用的功能。我觉得在实际的使用种出现这些问题根本就是正常的。
你觉得这段话除了是废话还能是什么呢？你随便抓个菜鸟过来他都能跟你侃出这么一通来，只要他脸皮够厚。假如我是一个刚接触J2EE的architect，我现在就要决定下一个项目用不用EJB，你的这段高谈阔论能给我什么指导？我当然知道“EJB有时适用有时不适用”，到底什么时候适用什么时候不适用，你说清楚了吗？你能帮我作出选择吗？
再重复一遍：“EJB好不好”绝对不是一个无聊的问题，这是一个architect要开始一个J2EE项目时要考虑的第一个重要问题。“为什么要使用j2ee而不使用.net”更加不是一个无聊的问题，这不仅影响你的architecture，甚至影响你的团队建设，甚至影响整个公司的经营方向，你能说这是个无聊的问题？这都是非常重要、非常需要考虑的问题，无聊的是某些人明明提不出任何有价值的意见却要不懂装懂，譬如你。
Top116楼 aico (aico)
回复人： jokerjava(冷血) ( ) 信誉：96 2004-04-22 18:03:00 得分:0
东西都让中间件做了 不放心 呵呵
---------------------------------------------------------
呵呵,如果交给自己做,则"更"不放心!!!
中国的IT业现在的情况大家想必都清楚 :
1)没有成型的产品(或者说很少,而且这其中多数是l15n的)
2)没有核心技术(拼命地跟在人家屁股后面学,学得好的自己就觉得好牛X啦)
3)项目开发的层次大都在金字塔的最顶上的那块石头上.(或者干脆就没有金字塔,在个土丘上挖个.net的洞,或者上面铺些jsp,struts的稻草,就算屋子啦)
4)客户(尤其是政府信息化项目), 随便"听听"你的技术,有叫的响就行,认真"看看"你的界面,没有漂亮的颜色不行.
5)众多的程序员,看了两天EJB的书, 知道EJB <= 分布式,就号称精通EJB乃至J2EE啦.
好浮躁的一个中国.
EJB是个标准,或者说规范. 中国的同仁们太习惯把它当成一个产品来看待了.
它是一个产品吗?不是. 它只是提供了一个思路,一个架构,支持你达到目的. 虽然
其中有很多糟粕( J2EE是个贪大贪全的东西), 但它的思想当之无愧的伟大.
我认为,对于我国大多数项目而言, EJB就不是这个时代的东西. 我们项目的时代, 至少
落后人家20年, 甚至更多, "能用至上,做出正确的业务来就好",已经是非常我们项目
甲方非常负责的态度了(那些只看界面的客户你没碰到过吗?). 对架构的要求, 系统
扩展,安全的要求(不要跟我说他们要求必须有密码啦 ^_^), 10年后的升级移植计划,
突发灾难应急方案, 呵呵, 有几个项目的文档里描述了啊(且不说实现啦).
国情既如此,盲目的应用先进技术,当然不见得是个好的解决方法.(客户不懂,程序员只
知皮毛,架构师才够水平侃侃, 这样霸王硬上弓, 项目不失败很难啊). 据称中国2002
年一切90%应用EJB技术的项目"实际"以失败而告终.
我想,咱们不能随便指点人家的东西,虚心一点,能学得深一点,人家的东西的好处说不定
咱就能看出多一点来, 尽量不要只停留在概念层次,就说人家好啦坏啦. 在我的印象中
西方搞软件的比咱中国的务实一些(不是崇洋媚外, 拿砖头砸我干啥啦). 把鬼子的东西
多学会一些, 我们就进步了一些; 如果咱们中国的程序员,每人都进步一些,会是怎样的
力量啊. 如果只停留在弄个jsp页面, 用个Connection连接数据库接着增删改查,呵呵,
跟鬼子就距离就越来越远啦.
Top117楼 Apple200228 (Apple)
先学习,再评,再改
Top118楼 huzhigang (hu)
呵呵。我水平如何我比你清楚，我同事和上司也比你清楚。这方面的事情我不会再反驳你，你说我差就差了。可惜你不是上帝，你说有光就有关。你觉得有意思那就继续说吧。我觉得无聊不说就行了。我若不起你这种牛人（你既然说我很差，那你肯定很牛了。你是第一个说我很差的人。我接收，谢谢你的评价）我躲的起吧。
Top119楼 Schlemiel (维特根斯坦的扇子)
to huzhigang(hu)：
请不要混淆概念。我不会从你同事或上司的那种角度来评价你的水平，因为我并不像他们那么了解你。我只会评价你回复的水平，这是我对你唯一的了解。不过可惜的是，你并没有在回复中体现出什么好的水平。不管你真实的水平如何，你的回复显得很无聊，这就是我的意思。
Top120楼 zkjbeyond (jigi)
huzhigang(hu)
坦率的说，这和讨论为什么要使用j2ee而不使用.net一样的没意义！我到觉得这有意义，要不我们开帖论论。
不过to huzhigang(hu)：，你真的是说了一堆废话，婆婆麻麻的。
Top121楼 huzhigang (hu)
就是就是，不说了。最近项目有些问题。就想找人吵架。不好意思。打搅你们讨论了。不说了。再见
Top122楼 steedhorse (晨星)
再见。
Top123楼 aico (aico)
呵呵，挺好的讨论，怎么吵起来了？
Top124楼 XIHSHI (西红柿)
好贴
up
&mark
Top125楼 asdmonster (呆鸟四号)
替 huzhigang(hu) 说句话：
ejb本来就是对rmi的oo封装，在ejb1.1乃至以前根本就没有cmr，说ejb是o/r mapping的解决方案无从说起。就象以前我找工作的时候总有人和我讨论bmp的“高效率”，没有什么实际意义。rmi,corba等都是都是面向分布式的，一个分布式的系统本来就是重量级的。一个分布式系统首先要考虑的问题是什么？O/R Mapping?总是听说ejb的开发效率低，以前开发ejb的时候没有觉得效率有多低，说入门的门槛比较高倒是真的，刚开始不熟练的时候总是要吃很多苦头。但是比较熟手以后调试的效率不见得低。
有一种说法叫时髦，我第一次听到hibernate是听楼主介绍的，但是听多了就感觉不是那么回事。有个刚开始学的朋友罗列了他学习java的顺序是：jsp->hibernate->struts->xml....，在省略号得很长一段名词里面，甚至有了J2ME,就是没有RMI,EJB,当时有很多人包括csdn里面的一些认为的高手都大叫good,但是真的是这样吗？如果在Open Source版块开个帖子问问struts,hibernate,spring等等名词，估计帖子能顶得天高，但是上次一个朋友开了一个帖子问j2ee中的安全机制，结果很搞笑，几乎没有人回答，偶有两个跟帖居然大骂发帖人是菜鸟云云（但是不是菜鸟的人水平又有多高？）。这几天有个叫robbincsdn的人发了一个讨论soap的帖子，还是参与者寥寥。难道大家觉得hibernate比j2ee安全机制，比soap更能体现技术含量？
当然，我并不是反对新技术，但是问题是在我们这个圈子里面，当大家都在讲“不要造轮子”的时候（这句话本身没错），是不是大家正在渐渐的忘记了怎么样造轮子？忘记了轮子怎么转的？
常常因为中国的程序员职业生命短暂而懊恼，不能说我们太浮躁，生活在这个环境下很无奈，但是很多时候是不是我们自己把自己绕进去了？对于楼主的问题，我唯一愿意说的就是，在没有hibernate,spring之前ejb已经成为j2ee体系的核心部分,即使将来hibernate,spring成为工业标准，甚至是j2ee的一部分（个人觉得几乎不可能，因为它们做的仅仅是解决了程序设计的某个方面，远远没有达到成为一种思想的程度），ejb也不会被j2ee标准所抛弃。更多的内容需要说吗？学到了自然就明白了——至少是我现在还没有明白。
我真的很奇怪楼主为什么提出这么一个话题，因为楼主提问题的时候难道没有想到这个问题在csdn这个小的圈子里面由你做了结论？
套用电影里面的一句话：这就是江湖！
Top126楼 javer6 (孤舟万里)
赫赫，“吵“起来了哦！
这是牛人之间的争论，我是菜鸟，无权回答！板个凳子来，听着！
当然，这只是技术性争论而已！
Top127楼 Schlemiel (维特根斯坦的扇子)
to asdmonster(快乐的土豆)：
你其他的观点我不想评价，这会时间也不早了。只点评你一句话。
>>但是比较熟手以后调试的效率不见得低。
每次修改EJB的代码，你必须花上一分钟左右（如果机器够快的话）执行整个编译、打包、发布的过程，然后才有可能执行单元测试。一分钟的时间，对于一个中等规模的项目，如果用轻量级方案的话，我已经可以把全部上百个单元测试执行一遍了。抛开其他所有因素，单凭这一点就足以让我对EJB敬而远之。如果你不是在一个敏捷团队中，如果你没有采用TDD，你不会知道这一分钟意味着什么。
所谓重量级方案的缺陷，往往就体现在这样一个个的“一分钟”里面。所以很多时候，如果不是一直从事工业级开发，你无法衡量一个方案的优劣。
Top128楼 Schlemiel (维特根斯坦的扇子)
另外，可能是我孤陋寡闻，我确实不知道SOAP有什么技术含量。如果你旁听过SOAP早期规范的制订，相信你也不会有这种错觉。
Top129楼 zkjbeyond (jigi)
asdmonster(快乐的土豆) 我也说两句
在ejb1.1乃至以前根本就没有cmr cmr只能算一个代名词，可能但他的思想对于一个数据库设计者来说肯定有。
说入门的门槛比较高倒是真的 我同意，现在很多人连面向对象也模棱两可就开发EJB，弄不出来就说EJB怎么样怎么样，我看不起这些人。
开源的东西 你要不E文不好，还是不要用。
hibernate,spring没弄过，给我讲讲吧。
EJB不可能退出J2EE的。 好向JSDK1.5 有个象DataSet(基于XML的对象)的东西了。那JAVA实现WEBDERVICE就没那么困难拉。SOAP可能会被封装很好的。
说错了多批评，这样讨论对我很有提高。呵
Top130楼 xiaoyao008 (JavaBean)
来晚了！接分！
Top131楼 totodo (土豆仙)
To: zkjbeyond(jigi)
假如一电信客户，要增加一新电话套餐业务。（我在unix服务器上）
IE上可以注册，手机可以注册，jsf(java\swing)程序可以调用。
那你们说业务逻辑要放哪儿，map o/r 怎么映射。
不但要用ejb，也要用扇子说的集群。
===============================
你也做OSS啊？
说说构架。
Top132楼 huhuchong (糊糊虫*努力学习中)
现在中国的程序员大多数英文不是很好(包括我,我在努力学习英文),开源的绝大多数资料都是英文的,对于我们这些英文不是很好的程序员来说自学有一点的难度,相对的,EJB的中文资料就多很多,中文版的书籍也出了不少(尽管多数翻译质量较差),所以,中国的程序员要想用好开源的东西,必须把英文水平提高上去. 我想这个也是中国软件水平为什么会落后于印度的一个主要的原因..
Top133楼 asklxf (xuefeng)
如果我是项目经理：
采用Spring,Hibernate...当然可以，但是：开发人员的培训费用，出现问题到哪里找技术支持？论坛？这些费用可能一点也不比weblogic或websphere便宜
如果选择成熟的商业化产品，比如weblogic，虽然软件投入多，但随时可以获得技术支持，服务器down掉了可以找他们解决。
所以，没有最优秀的解决方案，只用最合适的方案，技术上有优势不一定就是首选。
Top134楼 javer6 (孤舟万里)
现在好像争论到RMI了吧！说到RMI我还是有很多感触得！RMI我用它做过一个很小的项目，感觉对项目促进很大，主要是做一个小型会议系统，因为多个客户端的数据主要集中在服务器上，所以用RMI，就可以从服务器操纵各个客户端的动作，从这个逻辑上来说，业务逻辑就很简单，客户端的设计也相对作得很简单，它只要提供服务器访问的远程方法就可以，具体设计可以集中在服务器，做下来，感觉采用RMI最大的好处就是省去了服务器与客户端之间通信报文定制，以及多种包文应答处理机制，因为RMI已经帮助你实现了底层通信机制。这个技术对于C/S开发是令人振奋的。但是我现在最担心的就是它带来的对网络的通讯负荷，感觉它的传输量是用普通包文的好几倍。如果客户端多了，不知道网络层能否提供支持，我现在的会议系统只能运行在局域网里面，internet远远不行啊！
真实又爱又怕阿！
Top135楼 Schlemiel (维特根斯坦的扇子)
to javer6(孤舟万里)：
恐怕你很难找出比RMI更compact的RPC协议了，现在流行的很多RPC（例如JAX-RPC和Burlap）都是用XML。通用性是关键，大多数系统对性能的要求并不是那么高。不过会议系统倒真是难说。
我现在并不认为RMI是一个很好的RPC协议，主要是因为它不是通过HTTP传输。如果是需要通过Internet做RPC，HTTP传输几乎是必要条件。
Top136楼 javer6 (孤舟万里)
-->>>主要是因为它不是通过HTTP传输。如果是需要通过Internet做RPC，HTTP传输几乎是必要条件。
RMI是可以采用HTTP协议传输的，只不过HTTP传输协议的选择在采用socket直接传输bitearray失败之后。
Top137楼 wbh0360 (手中无剑，心中有剑，剑人合一:))
www.jdon.com上去看看
Top138楼 jacklondon (jacklondon)
全面反驳，以博一笑
1。EJB支持分布式系统，服务器级的集群，应用层组件的集群。
Tomcat 也支持服务器级的集群，开发 JSP + JavaBean 比开发 EJB 容易省心多了。
2。EJB支持容器管理的事务。
JDBC 也支持事务。
3。EJB支持通过配置文件来实现安全的机制，基于角色的访问权限控制。
实际上，比较大一点的系统，都会自己写用户/组/权限的验证，EJB 的安全验证只能适用于极少数情况，项目复杂一点就不好用。并且，从来没有资料证明，用 JSP 自己写用户验证安全性会比 EJB 差。
4。EJB 容器提供了连接池
Tomcat 也提供了连接池，比较新的 JDBC driver 也基本上全部提供了连接池。没有证据证明 weblogic 等 ejb server 的连接池会比其他的连接池好。
5。EJB支持MVC开发，分层开发，容易维护
JSP 也支持MVC开发，分层开发。其实用 PHP,ASP 只要规划好，使用模块化开发一样容易维护。没有证据证明，用 EJB 做的项目容易维护，而不用 EJB 的项目就不容易维护。
6。EJB提供多线程解决方案
很奇怪的说法。EJB 只是对 JDBC 数据访问进行了高级包装，在 EJB 中不能用线程,不能访问本地文件,怎么会有人这么想?
7。熟悉EJB架构
呵呵，有一种说法，提着榔头，看到什么东西都想用榔头敲一下。如果用 JSP 就可以做的项目，为什么要用EJB？想表现自己的本领？没有必要。由于用 JSP 做项目比EJB快，我可以少加班，谢天谢地！
8。entity bean的O/R mapping
早在 MFC 的年代，VC就可以为每个数据表自动生成一个包装类。实际上，只要用过 O/R mapping 的人都知道，O/R mapping 只适合于单个表，或者master/detail 表，更复杂一点就歇菜了。像 Office 97 中带的“罗思文商贸系统”这样小型的数据库，O/R mapping都很难搞定，更别说复杂系统了。其实更多的人，对于复杂系统都是自己写 JDBC/ADO/ODBC 来管理数据的。我从不看好O/R mapping。
9。ejb容器帮助实现了对象持久性。
实际上，对象持久性我所知道的只有一个是好的，那是在VC中。其他的对象持久性都是非常糟糕。Java 的 Serializable interface 没有一个函数，这么怪的设计也只有 Sun 才能做出来。Serializable 大可以放到 Object 基类中，这样对于程序员可以少写很多代码。
10。EJB 有 Entity Bean, Session Bean。
Entity Bean 的设计本意是将数据加载到 EJB server 的内存中，加快速度。实际上， database server 已经做了这一步，并且比 Entity Bean 做得好得多。Entity Bean 速度之慢令人难以忍受。 Session Bean 的设计本意是在集群中，能够在多台服务器中间保存状态。不过既然 Tomcat 已经可以支持集群了，JSP + Tomcat 比 Session Bean 无论在开发速度，运行速度上面都有很大优势，所以Session Bean也没有多大用。
11。消费JMS异步消息
早先，我一个朋友对于 MSMQ 很着迷，我相信他在国内在这方面也是数一数二的。他用 MSMQ 做了几个项目。后来我对他说，只要他将数据都放在数据库中，所有模块都通过数据库通讯，这样程序更容易写，效率也更高。他用了很长时间才明白。他这是犯了典型的“提着榔头，看到什么东西都想用榔头敲一下”的毛病。
12。提供与CORBA客户端的互操作
这有点像是用大炮打文字。CORBA虽然是一个比较老的标准，可以易用性不如 COM/DOM， 它的用户/程序员也不太多。不过现在CORBA工具已经有一些，用这些工具比用 EJB 更好地解决与CORBA客户端的互操作。只需要用CORBA工具写一个用作通讯转发的 class 即可。
我看不出为什么要用 EJB。EJB更像是 Sun 的宣传口号。在宣传中，EJB适合于企业级应用。“企业级应用”是什么？一定要用EJB吗？没有几个人能够说清楚。
Top139楼 asdmonster (呆鸟四号)
全面反驳，以博一笑
1。EJB支持分布式系统，服务器级的集群，应用层组件的集群。
-----------------------------------------------
集群并不是ejb独有的，更准确的说也是ejb的那种容器管理模式的容器提供的集群能力，没有人说ejb唯一的提供了集群的能力，只能说它具有了这样的能力为企业开提供了便利。
2。EJB支持容器管理的事务。
----------------------------------------------
二者的事务控制根本就不在一个层次上，更准确的说，jdbc提供的事务j2ee事务的最低级别。
有个设计理论是“粗粒度控制”
3。EJB支持通过配置文件来实现安全的机制，基于角色的访问权限控制。
---------------------------------------------
安全不是你所说的“name/password”那么简单。
4。EJB 容器提供了连接池
--------------------------------------------
第一，Weblogic对连接池的支持就是比tomcat强大，第二，这和我们讨论的主题有关吗？（我们没有说ejb的每一项技术都是独一无二滴）
5。EJB支持MVC开发，分层开发，容易维护
-------------------------------------------
EJB支持多层结构，不支持MVC，"MVC is only UI Designer."
6。EJB提供多线程解决方案
------------------------------------------
呵呵。
7。熟悉EJB架构
------------------------------------------
呵呵。
模式的一个定义是对解决某一个方面的问题的经验的总结。
8。entity bean的O/R mapping
--------------------------------------
呵呵，脱离了多表，O/R mapping的R从哪里来？
9。ejb容器帮助实现了对象持久性。
--------------------------------------
VC中的哪个？ODBC?DAO?ADO?OLE DB?记得刚开始学习struts的时候我也问过给我讲课的讲师，为什么没有 UpDate()呀？
10。EJB 有 Entity Bean, Session Bean。
--------------------------------------
呵呵。
11。消费JMS异步消息
------------------------------------
j2ee的所有规范都仅仅是为了某个机制的java实现提供一个框架的定义.
呵呵。
12。提供与CORBA客户端的互操作
------------------------------------
呵呵。
我看不出为什么要用 EJB。EJB更像是 Sun 的宣传口号。在宣传中，EJB适合于企业级应用。“企业级应用”是什么？一定要用EJB吗？没有几个人能够说清楚。
----------------------------------
呵呵
Top140楼 javer6 (孤舟万里)
： jacklondon(jacklondon) (
从你的回复中可以看出你知识的肤浅！而且是那种典型的半桶水主义！
刚看到低一点，我就知道接下去的东西没必要看了！浪费精力！“开发 JSP + JavaBean 比开发 EJB 容易省心多了。“。EJB根本没有定位在这种简单的web框架上！这种可比性简直是在糟踏EJB的作者！
Top141楼 WAPQQ (我希望一切会变好的)
方便系统升级
开发速度比较快
Top142楼 asdmonster (呆鸟四号)
几块砖：
-------------------
的确每个方面现在ejb都有了替代，技术总是要发展的。我相信过几年整个j2ee都会发生天翻地覆的变化。
个人觉得，ejb本身之所以成为j2ee的核心，因为它囊括了j2ee的很多方面（也因此显得笨重）。
如果选择ejb，除了某些非技术的理由，需要一个企业级别的应用，企业级别的涵义是：大数据量大访问量（因此可能需要集群），高稳定性（因此可能需要冗余等）,高安全性(因此可能需要采用额外的安全技术)
说到EJB,不可能不说RMI,记得有位朋友说过rmi可以看作corba的pure java实现我看很有道理（我对rmi的实现确实了解很少）。corba,rmi其实都是为了解决一个远程调用的问题，个人觉得远程调用中最关键的问题不是通用性，而是两地之间的平台差异，通讯中的数据安全。最早的RPC就是基于此存在弊病，基于XML的RPC主要是应用了XML的跨平台性，但是安全上的问题还是没有完全解决（或者解决得并不完美）。corba,rmi采用的完全是代理的做法，然后在两地之间进行参数和处理结果的 marshal/unmarshal的动作。基于此，永远不要指望RMI单纯的采用TCP/IP进行通信，通用的通信协议是IIOP（事实上EJB可以和ORB通信也是IIOP的能力而不是EJB自己的固有内容），当然各个服务器提供商都有自己的通信协议，比如Weblogic的t3,EAServer的tds。（btw:所谓的协议，不过也就是那个七层协议的不同层次的解释）。
AppServer，我不知道应不应该把AppServer算作Ejb规范的一部分。AppServer包括了太多了内容， ejb池当然不肖说，还有jndi(名字目录服务),jms（消息机制）等(再列举下去就是堆砌名词了)。各个方面的重要型不需要多嘴吧。
常听有人说ejb是笨重的解决方案，xxx是轻量级的首选，比如单纯的o/r mapping没法子和hibernate比，做容器spring实现的voc的概念很先进，持久化，jdbc要快得多,ldap也可以用做目录服务器，单纯的Message Server太多了。但是问题是，你要解决什么问题，当你面对一个大的系统的时候，你是愿意用ejb，还是愿意来一个hibernate+spring+ldap？首先无缝组合就是一个问题。这种情况不多，但是现实生活中存在。（我们的j2ee做了几个大项目？）
ejb的确显得有点慢，但是一个项目过程中，编码调试本来就是一个很小的单元，一个系统，特别是一个大的系统，真正耗费时间的设计阶段，需要理顺的各种业务逻辑（这和敏捷开发并不矛盾）。项目越大，”那几分钟“的影响越小，不是吗？
btw:
ejb本身并没有限制其实现，将来有一天，Weblogic的实现是用hibernate来实现其持久化（这种场合用持久化我觉得更合适，当然那时候可能还是一样的慢，大家可以test一下，new InitialContext()很慢），容器的控制方式也类似于Spring，都有可能，就象整个j2ee,ejb也仅仅是一个框架。
呵呵，板砖而已。
Top143楼 jacklondon (jacklondon)
其实我更看好 RMI，不过它也没有做好，而且 Sun 没有明确的改进它的计划，让人失望。
其实我在 EJB 项目中，都会写一个封装函数，然后这样用
obj = EJBTool.getObject(objectName,returnClass);这样代码简洁很多。当然这是参照 VB 的调用 COM/DCOM 的写法。
后来我就想，既然我每次都要这样写，为什么不建议 Sun 公司对EJB/RMI 进行简化，以后我们写 EJB 程序更容易写？
EJB 的 SessionBean, EntityBean 用 java interface 也很成问题。因为如果以后 EJB 3.0 在这两个interface 中增加函数，我们写的 SessionBean, EntityBean 都不能编译通过。这个问题我问过Joshua Bloch，但是他也不能解释为什么 Sun 为什么这样设计。其实这里应该把SessionBean, EntityBean设计成 class 而不是 interface.这样我们每次写 SessionBean 也可以少写几个空函数。这几个空函数每次都要写！！！很不好的设计。
Top144楼 zkjbeyond (jigi)
同意javer6(孤舟万里)
jacklondon(jacklondon)
你可真弱滞，真想小你。
你的上一贴就够恶的了，被人批了还写。
首先我先说说我对RMI的理解，有不对的大家可以指正。
RMI是在JDK发展到1.1加进去的，实现对象的远程访问。JDK的rmic工具可以完成大部分的工作。
RMI由少量的类、接口和简单工具组成。你可以花半天就可以写出远程的HelloWorld服务器。实现他是简单的。然而，设计一个高效的、能够满足各种功能的RMI服务器就难了，你必须对每个远程方法都考虑传入什么参数。可看你
《其实我在 EJB 项目中，都会写一个封装函数，然后这样用
obj = EJBTool.getObject(objectName,returnClass);这样代码简洁很多。当然这是参照 VB 的调用 COM/DCOM 的写法。》知道你设计不了RMI。
RMI象大多数分布式架构，RMI不象EJB，开发者必须考虑线程安全性等系统极问题，实现起来我估计，想想就困难。
Top145楼 zkjbeyond (jigi)
《obj = EJBTool.getObject(objectName,returnClass) 》大哥你一个调用EJB就象调用一个本地对象简单啊，那可是远程调用啊。
COM/COM+是组件模型，要实现远程调用用WEBSERVICE或.NET的远程调用接口。COM/COM+是MS DNA架构。现在dotNet推WEBSERVICE。 你要知道EJB是分布式组件模型。一定要加分布式。
《为什么不建议 Sun 公司对EJB/RMI 进行简化，以后我们写 EJB 程序更容易写？ 》企业级应用不可能简单，我个人估计会更复杂，开发企业级系统没5年经验肯定不行。EJB不是入门的东西。
《EJB 的 SessionBean, EntityBean 用 java interface 也很成问题。因为如果以后 EJB 3.0 在这两个interface 中增加函数，我们写的 SessionBean, EntityBean 都不能编译通过。这个问题我问过Joshua Bloch，但是他也不能解释为什么 Sun 为什么这样设计。其实这里应该把SessionBean, EntityBean设计成 class 而不是 interface.这样我们每次写 SessionBean 也可以少写几个空函数。这几个空函数每次都要写！！！很不好的设计。
》
大哥你不要笑死我啊。类和接口你也分不清啊。 居然还叫空函数，你是HelloWorldEJB看多了。
Top146楼 peigen (比碗浅)
小弟我也说两句吧。我是初学者阿。
如果，没有用，那么，我学它有什么用呢。
我为什么还要学它呢，我不学就考试过不了，过不了就拿不到证书，拿不到证书钱就白扔了，钱花了还没有证书妈妈就会伤心难过，妈妈难过了我也不会好过，就这么简单。
所以我没有理由不学，没有理由不学好。
在一个已经决定一心扑在java上的人来说，即便EJB是垃圾，甚至什么都不是，我还是要学它，要学好，我要用，未来要用，以后要用，“让自己好过”。
我也没有理由新论坛上的争论，不信SUN吧。
Top147楼 rushfly (天圆地方)
啊，学习中,向牛人们问好！！！
Top148楼 li_shyng (乡村里的土狗)
我认为只有在两种情况下才使用EJB
1、应用中有分布的数据源；
2、要远程调用服务器的方法；
其他理由都不能构成使用EJB的理由
Top149楼 jacklondon (jacklondon)
我不知道是有些人语文水平差，还是故意捣乱。在此举例加以解释。希望语文水平差的反复读几遍。代码中用了中文空格，仅供参考，代码不一定能编译使用。
EJBTool.java
import java.util.*;
import java.io.*;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.naming.Context;
import javax.rmi.PortableRemoteObject;
import javax.management.j2ee.*;
public class EJBTool
{
public static Object getObject(String objectName, Class returnClass){
try{
//get context object
InitialContext ctx = null;
Properties env = new Properties();
env.load(new FileInputStream("config.properties"));
ctx = new javax.naming.InitialContext(env);
//find object
Object ref = ctx.lookup(objectName);
String homeClassName = returnClass.getClass().getName()+"Home";
Class homeClass = Class.forName(homeClassName);
ref = PortableRemoteObject.narrow(ref, homeClass);
ref = ((ManagementHome)ref).create();
if(returnClass.isInstance(ref)){
return ref;
}
}catch(Throwable t){
System.err.println(t);
}
return null;
}
}
这样不必每一次调用 ejb 都要写重复的 lookup 代码。
CountBean.java
public class CountBean implements SessionBean{
private int val = 0;
private SessionContext ctx;
public int count(){
return ++val;
}
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
}
如果 SessionBean 本身不是 java interface 而是 java class, 就可以这样写
CountBean.java
public class CountBean extends SessionBean{
private int val = 0;
private SessionContext ctx;
public int count(){
return ++val;
}
}
对于每一个EnterpriseBean，可以少些很多垃圾代码。如果有100个 EJB bean, 可以至少少写 100*4 行代码。
实际上我在写代码的时候，总要写一个 BaseEnterpriseBean,
BaseEnterpriseBean.java
import javax.ejb.*;
public class BaseEnterpriseBean implements SessionBean,EntityBean,MessageDrivenBean
{
private EJBContext m_context = null;
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void ejbStore(){}
public void ejbLoad(){}
public void setSessionContext(SessionContext ctx){
m_context = ctx;
}
public void setEntityContext(EntityContext ctx){
m_context = ctx;
}
public void setMessageDrivenContext(MessageDrivenContext ctx) {
m_context = ctx;
}
public void unsetEntityContext(){
m_context = null;
}
public EJBContext getContext(){
return m_context;
}
}
这样，即使 j2ee/jdk 的新版本往 SessionBean 中增加函数，我也只需要修改BaseEnterpriseBean.java,不需要每个 EJB bean 都必须增加新的空函数。
这样，CountBean 换了一种写法
CountBean.java
public class CountBean extends BaseEnterpriseBean{
private int val = 0;
private SessionContext ctx;
public int count(){
return ++val;
}
}
同样少写了很多代码。
Top150楼 zxs790501 (沧海一粟)
好帖，值得收藏！
学习～～
Top151楼 zkjbeyond (jigi)
我们讨论的是EJB结构和功能，转儿想得到使用EJB的约束。
每个人都有自己的写法，你这样实现可以啊，可好象你的实现对EJB命名好象有点要求吧。
Top152楼 zkjbeyond (jigi)
企业Bean的优点
由于以下的原因，企业Bean大大简化了分布式应用的开发。首先EJB容器给企业Bean提供了系统级服务，使Bean开发者可以专注于商务问题的解决。是EJB容器而不是开发者负责项事务处理和安全授权等系统级服务的管理。其次因为企业Bean而不是客户端实现商务逻辑，客户端开发者就可以致力于客户端表述的开发，而不必为实现商务规则或者数据库访问的日常处理而编码了。结果使客户端“瘦”了许多，很明显，这个有点对于在小设备上运行的客户端来说是很重要的。最后，因为企业Bean是可移植的，应用程序组装者可以用现有的企业Bean建立新的应用程序。这些应用程序可以在任何兼容的J2EE服务器上运行。
何时需要使用企业Bean
如果你的应用程序符合以下的任一条件，你就应该考虑使用企业Bean：
· 你的应用程序需要不断的升级。为了适应不断增长的用户，你可能需要将你的应用程序组件分布在多台不同的机器上运行。虽然并不仅仅是企业Bean可以在不同的机器上运行，但企业Bean的运行位置对于客户端始终是透明的。
· 需要用事务机制来保证数据完整性。企业Bean支持事务机制以提供对共享资源并发访问的管理。
· 应用程序需要支持众多不同类型的客户端。只需要极少的几行代码，远程客户端就可以很容易的访问到企业Bean。这些客户都可以很“瘦”并且在理论上可以是任意数量不同类型的客户端。
Top153楼 zkjbeyond (jigi)
这是J2EETutorialTranslation的一段话
希望大家可以在这基础上来讨论，我先开头
1、客户端：可以是WEB程序，JSP，SERVLET； 可以是PDA等小设备 ； 可以是JFS,java桌面程序，如果把EJB发布成WEBSERVICE，那客户端就更多了。
2、我个人觉得EJB的可移植性不高了，就J2EE服务器不同厂家区别就很多，反正我看WEBSPHERE里加了很多IBM的类库。不过我想既然选择了一个application server，那移植就没什么必要。
3、EJB项目确实有很多失败，我多么希望这些失败的经验可以让我们分享一下。2001年，以前公司根据MS的DNA架构开发了一套税务征收系统，虽然算成功了，可效率，稳定性一直有问题。在持久数据这块没有个好办法。COM+速度也不行。（难度不比EJB容易多少） 我感觉EJB好象这方面可以让我们非企业级程序员少操心。
共享访问
EntityBean可以被多客户端所共享。由于多个客户端可能同时去修改同一数据，所以在调用过程中事务机制非常重要。典型情况下EJB容器都支持事务机制。在这种情况下，可以在Bean的部署描述符中确定它的事务属性。开发者不必为事务界限编码——容器会自动划分事务界限。
4、应用程序需要支持众多不同类型的客户端，个人觉得这是个方向。SUN，MS都来争这块蛋糕。
Top154楼 iwhp (有数 upForever)
就是锻炼人的脑子
Top155楼 coolyzg (JMan)
可以拿高工资啊
Top156楼 zkjbeyond (jigi)
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
你就是helloworldEJB看多了。
不得不写的垃圾代码，哈笑死我了。
Top157楼 jacklondon (jacklondon)
请教 zkjbeyond(jigi) 写一两段你所谓不是helloworldEJB的代码让大家瞻仰瞻仰。
Top158楼 zkjbeyond (jigi)
好。看好啊。
先是有状态会话Bean的生命周期，居然说是 垃圾代码
有状态会话Bean的生命周期：
从不存在到准备就绪到钝化，然后原路返回。
客户端调用create方法(该方法在Home或者Local Home节口中声明)就开始了一个有状态会话Bean的生命周期（在此之前是Does Not Exist，不存在阶段）。EJB容器产生一个Bean的实例然后调用Bean类的setSessionContext和ejbCreate（和Home或者Local Home节口中被调用的create方法对应的ejbCreate）方法。这时该Bean实例进入准备就绪状态（Ready），它的商业方法可以被客户端调用了。
在就绪状态，EJB容器可能会把该Bean实例从内存中移出到外存以钝化该实例（EJB容器一般采用最近最少使用原则来钝化内存中的Bean实例）。其实就是把内存中EJB容器认为暂时不会用到的Bean实例转移到外存中，以提高内存使用效率，这好像是支持多线程操作系统的内存管理。在钝化Bean实例之前，EJB容器会先调用ejbPassivate方法，所以你如果想在钝化之前做什么动作的话就可以在该方法里实现。如果钝化期间有客户端调用该Bean实例的商业方法，EJB容器将该实例读入内存激活它回到就绪组状态（很有点线程的状态变化哦），同时调用该Bean类的ejbActivate方法。所以你要在Bean实例被激活的时候做点什么动作的话，就在这个方法里动点手脚就OK了：）
在企业Bean的生命周期最后，客户端调用remove（同样是Home或者Local Home接口里的）方法然后容器调用Bean类的ejbRemove方法结束了一个实例的生命。该实例就乖乖的等待垃圾收集器的召唤了，不知道等待黑白无常的心情如何，哎你认命吧，Bean兄弟。
在这些生命周期方法中，你可以在客户端编码调用的只有两个：create和remove方法（呵呵，上面说过一遍了），例如，ejbCreate方法在Bean类里，允许你在Bean类实例化后执行一些特定的操作，比如你想让它自己实例化后就报个到，喊一声“我来了”，那把代码塞在这个方法里面就没错了。或者你是想让它跟要访问的数据库打个招呼，建个连接也在这里。
实体bean比这还复杂，还有同步数据等。
Top159楼 zkjbeyond (jigi)
你的BaseEnterpriseBean只是实现了那些方法为空。你的实现bean里需要是你还是要实现的。
有一部分无状态会话bean 是不需要那些方法的。
即使 j2ee/jdk 的新版本往 SessionBean 中增加函数， 可以看出来你只是个coder。
j2ee/jdk的新版本不只是为了某些函数而升级的。
你可以看看jdk1.5的新功能。呵
其实EJB也在效率上，难度上有改进。
例如本地访问和远程访问
我们可以根据一下因素来决定是选用远程访问还是本地访问：
l CMR：如果一个企业Bean是CMR的靶子，那么它必须实现本地访问。
l 企业Bean之间的关系是紧耦合还是松耦合：紧耦合的企业Bean互相依赖。例如一个订单必须有一条或者多条商品条目，这些条目脱离订单就毫无意义。表示它们的EntityBean OrderEJB和LineItemEJB是典型的紧耦合模型。紧耦合关系的企业Bean一般都在同一个商业逻辑单元里，而且他们通常会用频繁的相互调用。所以最好考虑在紧耦合的企业Bean之间使用本地访问，会大大的提高性能。
l 客户端的类型：如果企业Bean是被J2EE应用程序客户端访问，那么它必须允许远程访问。在生产环境中，客户端大多数情况下运行在和J2EE服务器不同的机器中。如果客户端是Web应用或者其他的企业Bean，那么它们也可以和被访问的企业Bean部署在同一个环境中，访问方法也取决于如何部署应用程序。
l 组件部署：J2EE应用程序是可升级的，因为服务器端的组件可以本分布在多个不同的机器中。例如一个分布式应用程序的Web应用可以运行在与它调用的企业Bean不同的服务器中。在这种分布式场景下，企业Bean必须允许远程访问。
如果你还不能确定使用哪种访问方式，那就选择远程访问。它可以让你的应用程序更灵活——在以后你可以任意分布部署你的应用程序组件以适应不断增长的需求。
虽然很少这样做，但企业Bean也可以两种访问方式同时与允许，这样它就要同时实现Remote和Local两组接口。
Top160楼 minghuitian (明月)
gz
Top161楼 jacklondon (jacklondon)
to zkjbeyond(jigi) ,
这点垃圾谁不懂？也好意思拿出来蒙人？
Top162楼 zkjbeyond (jigi)
就是给你这垃圾看的，吗的，非老半天劲给你这垃圾看，还不领情，以后再也不理垃圾人了。
以下难道不是你这垃圾写的吗。
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
Top163楼 jacklondon (jacklondon)
关于 java interface 由于 jdk/j2ee 升级问题不能在新版本 jdk/j2ee 下面编译，我已经和 Joshua Bloch 讨论过，他只是说 java interface 是 java 语法中的精华，对于版本不兼容问题避而不谈。对于我和 Joshua Bloch 的 email 我改天贴出来让大家瞧瞧。
在 “Java 的JDBC 数据库连接池实现方法” http://www.csdn.net/Develop/read_article.asp?id=21140 中我写了这么一段话（不好意思，懒人不喜欢写重复的东西）：
Java Interface 是“不能修改的”，意思是无论增加函数还是删除函数，都会造成原有的代码不能编译通过。比如说 , JDBC driver 一块用了大量的Java Interface，某一个 JDBC driver (比如 Mysql JDBC 2.0.14)用了 java.sql.Connection, 在 jdk1.1 顺利编译通过。我用它做了一个项目。一两年以后，我用 JDK1.4 重新编译原来的代码，编译不能通过。原因是 JDK1.4 中的 java.sql.Connection interface 增加了很多函数。升级开发工具导致原来的代码不能编译通过是不能接受的。Borland 的 CBuilder 曾经犯了这个错误，结果导致程序员的普遍反感，大量的程序员转向 Visual C++ ----因为程序员们想，我现在写的代码以两年以后就不能编译通过了，到时候我不是要重写所有的代码？基本上而言，JDK 不同版本存在的编译不兼容问题，大部分都是 java interface 做的恶。如果你用了其他人的 java code, 或者你做的 java code 给其他人用，千万不能用 java interface, 否则以后升级导致编译不通过会导致吵架---我碰到过哟。现在我写代码基本上不用 java interface。
如果有人认为 j2ee/jdk 的新版本往 SessionBean 中增加函数,那是不可能的。开发工具由于竞争的需要，会不断增强。每个 class/interface 都有增加新函数的可能。
EJB bean 之所以要做组件池，原因在于 java 的一个大硬伤：new 操作非常的慢，相当于1000倍以上的赋值语句。在大多数性能优化的书中，都会提到，尽量避免 new；特别是需要长时间运行的程序，最好要把需要的 object 缓冲起来。这就是 EJB 组件池的设计由来。但是EJB 组件池只是略微改进了性能，而且大多数 EJB server 在这方面都做得不太理想。Apache web server 有一个内存池，比较好，EJB server厂商需要多多学习。
EJB bean 的Activate/passivate更像一场游戏，既然性能方面的好处不大，Activate/passivate就显得多余。
我写BaseEnterpriseBean的原因是因为可以在 CountBean这样的 EnterpriseBean避免写垃圾空函数。如果有100个CountBean这样的 EnterpriseBean，可以少写400行代码。效果是明显的。
Top164楼 onefox (一品狐)
这帖子题目本身就是火药桶！
去稍有人气的论坛放一个就能着火。
骂帖没必要，况且这里已经在骂人了
呵呵呵……
Top165楼 jacklondon (jacklondon)
EJB 简化是必须而且可行的。
比如我写一个 CountBean这样的 EnterpriseBean,可能需要写多个 java class文件: Count, CountLocal, CountHome,CountLocalHome,CountBean,外加一个 xml 文件。
大家心里都明白，除了CountBean有点有用的代码，其他几个 java 文件都是摆设。既然这样，为什么我们要去写呢？为什么不能由工具自动生成呢？最好我只写CountBean，我看到的代码只有CountBean，其他的在我编译CountBean时候自动生成。就像 VB 写 COM/DCOM 一样，程序员看到的源代码只有他自己写的，其他的附加代码都在编译时候自动生成，代码看起来很爽。
进一步想，既然其他java文件是没有必要，编译时自动生成也没有太多的必要。xml 文件也可以放在 CountBean中用 property 的 get/set 来做。这样一来，每个 EnterpriseBean就只有一个文件，不是简化了很多而且没有什么功能损失？
COM/DCOM 可以在一个最终发行的DLL中放一个或者多个组件。Javabean 由于java中没有合适的语法控制class 在 bean 内部 public而bean 外部 private,很多人并不把 javabean当作组件开发。EnterpriseBean虽然被当作组件开发的一种技术，但是它并不包含基本的版本信息（可能以后Sun会增加近来，加入版本信息技术难度很低）。然而EnterpriseBean一个最终发行文件能包含多个EnterpriseBean吗？
我想起来 ANSI C++ 败于 VB 的一个基本原因，在于它没有制定以及可用的发行组件的文件标准。其实它可以挑选 Unix 下面的共享库或者 windows 下面的 mfc dll(可以放 class, 不是普通的只能放 function 的dll)作为标准。或者它可以制定新的文件格式作为标准（难度也不大）。Java 在这方面似乎也在走 ANSI C++ 的老路。一个好的组件文件标准可以让软件厂商更好地合作。
Schlemiel (维特根斯坦的扇子) 哪里去了？他的帖子他不吭声，让我在这里撑着，不好意思吧？
Top166楼 zkjbeyond (jigi)
你快算了吧， 连接池代码网上多的是， 缓存的概念不是你写个破连接池就能掌握的，synchronized一下那就是缓存了，笑话。 写个连接池只说明你可能明白了 单例模式和有个低层次缓存的思想。
可我又觉得你没真正弄明白缓存，因为你不知道EJB里对象池的概念，连钝化和激活也不知道，那缓存个什么啊，EJB慢真正原因是远程调用。
我没说BaseEnterpriseBean没用，可你说
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
我就想不明白。
我估计你没看过实体BEAN的例子。这些函数说是垃圾，真失望。
Top167楼 sunvsh (sunv)
zkjbeyond(jigi)：
你不要张嘴舞脚好不好，地球人都知道你最行好了吗，尽看到你的烂贴，让我等来学习的人乱废时间，我觉得斑主是我学习的偶像，你应该向他学习，有点风度(不要像我这种菜鸟一样哦)！
Top168楼 zkjbeyond (jigi)
太让我失望了，含泪最后一帖。
EJB bean 之所以要做组件池，原因在于 java 的一个大硬伤：new 操作非常的慢，相当于1000倍以上的赋值语句。
为什么java没象c++那样用指针，不是你我能说明白的。每种编程语言都有自己的数据处理方式。有些时候，程序员必须时刻留意准备处理的是什么类型。您曾利用一些特殊语法直接操作过对象，或处理过一些间接表示的对象吗（C或C++里的指针）？
所有这些在Java里都得到了简化，任何东西都可看作对象。因此，我们可采用一种统一的语法，任何地方均可照搬不误。但要注意，尽管将一切都“看作”对象，但操纵的标识符实际是指向一个对象的“句柄”（Handle）。在其他Java参考书里，还可看到有的人将其称作一个“引用”，甚至一个“指针”。创建句柄时，我们希望它同一个新对象连接。通常用new关键字达到这一目的。
《〈〈你说new 操作非常的慢，你不要用java了，我不知道写程序的不用new那会怎么样〉
〈〈EJB 简化是必须而且可行的。
比如我写一个 CountBean这样的 EnterpriseBean,可能需要写多个 java class文件: Count, CountLocal, CountHome,CountLocalHome,CountBean,外加一个 xml 文件。
大家心里都明白，除了CountBean有点有用的代码，其他几个 java 文件都是摆设。既然这样，为什么我们要去写呢？为什么不能由工具自动生成呢？最好我只写CountBean，我看到的代码只有CountBean，其他的在我编译CountBean时候自动生成。就像 VB 写 COM/DCOM 一样，程序员看到的源代码只有他自己写的，其他的附加代码都在编译时候自动生成，代码看起来很爽。〉〉
我想问你java远程调用的机制是什么，协议是什么。 EJB大大简化了我们开发企业级应用程序的思路，可你还闲它麻烦。 确实MS给我们提供了很大的方便，你用DCOM,COM+可能已经用了window server多少东西了。那是个人选择的问题，你用MS的东西谁也管不着。你去google查找DLL 灾难，你就知道dll的版本问题了。
〈进一步想，既然其他java文件是没有必要〉我真的不知道有哪个java文件没有必要。说话前先弄明白再说。哪个java文件没用了。着失望。
Top169楼 asdmonster (呆鸟四号)
搂主，结帖吧。
虽然你的出发点是好的，但是java版太多的争吵了。
Top170楼 jacklondon (jacklondon)
to zkjbeyond(jigi) ,
建议你进入小学或者初中进修语文，你的中文阅读理解能力太差了，不要告诉我你的母语不是中文！！！！
你知道 EJB 用钝化和激活、组件池做什么？不就是希望性能优化么？既然性能优化不好，为什么不把这些去掉？这样更简单！！
“比如我写一个 CountBean这样的 EnterpriseBean,可能需要写多个 java class文件: Count, CountLocal, CountHome,CountLocalHome,CountBean,外加一个 xml 文件。
大家心里都明白，除了CountBean有点有用的代码，其他几个 java 文件都是摆设”，这句话很简单，你都看不懂。这里的 java 文件有：Count.java,CountLocal.java, CountHome.java,CountLocalHome.java,CountBean.java,我说除了CountBean.java文件，其他的java文件详细如下！！！！！：Count.java,CountLocal.java, CountHome.java,CountLocalHome.java.这几个java文件都是垃圾。
BaseEnterpriseBean中垃圾
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
我说他们是垃圾因为既然我不想写 ejbActivate 代码，我自然也不想写ejbActivate 空函数放在这里摆架子。为什么要写空函数？有何意义？有何价值？既然 ejbActivate 是可写可不写，就不应该放在 java interface 中，因为 java interface 中的函数都是必须要写的。比如 jdbc driver 在 implements java.sql.Connection 后，不可能把 Connection 中任何函数写成空函数。
用 COM/DCOM 文件由于有版本信息，同样版本的 COM/DCOM 不会在同一机器上有多个文件，安装程序也很容易判断要不要复制某个 COM/DCOM 文件。VB/VC的虚拟机同样的版本在通一台机器上永远只有一个。
你知道weblogic 安装后有几个 struts.jar 文件？23个!!!如果你卖给客户两套 EJB 产品，它们中间有一些共同BaseEnterpriseBean，你还是不得不在安装程序中复制多个同样的文件。
同样的问题对于 JVM 也适用。比如我安装了最新的 JDK/J2EE,我在安装 JBuilder,JBoss, weblogic 的时候 jdk 文件还是会复制，有何理由？
这个问题的解决，看来已经有一些眉目了。Sun 准备想出一种跨平台方法配置文件，可以在 java 程序中存储信息，类似于 windows 的注册表。这样 sun 可以把 JVM 的安装信息放在配置文件中，每次安装/发布 EJB 组件的时候，往配置文件中写相应的安装信息，就如 COM/DCOM 一样。
DLL 灾难问题是以前，现在已经好多了。如果说COM/DCOM 存在这种灾难，那么EnterpriseBean就是世界末日了。
Top171楼 lindex (this)
我们好不容易学会了多用户操作系统，也知道怎么安全的编制适合于分布式应用的应用程序组件了，学会了面向对象后，就学会了封装，把什么都封装在一个框架里头，来几个什么英文缩写就。。。。。。。。
Top172楼 asklxf (xuefeng)
两点建议：
1. 楼主赶快结贴，不要继续吵下去了
2. To jacklondon(jacklondon)：建议你仔细看看EJB Design Patterns和Core J2EE Patterns，尤其是Locator模式，如果你用weblogic开发，看看BEA的GernerateEJB代码你就明白了。
不要试图认为自己解决了EJB的一个大缺陷，事实上早就有普遍适用的设计模式了。
如果你看了SUN的EJB技术内幕，你就明白了设计师为什么要这么设计EJB，如果你自己实现分布式，事务，安全，多线程，缓存....等你设计出来J100EE都有了，毕竟SUN的设计师也不是吃干饭的，至少比我等在座的强100倍。
Top173楼 jacklondon (jacklondon)
to asklxf(xuefeng),
既然是讨论，自然有说好的，有说坏的。
有比较才有认识。我只不过说了我自己的想法，我相信我对于模式的应用不会比你差。
"毕竟SUN的设计师也不是吃干饭的，至少比我等在座的强100倍"----那又怎么样？ Sun 网站上面 JDK/J2EE 的 bug list 成千上百，还不是众多菜鸟们发现的？
Sun 公司一向喜欢夸大产品，把 EJB 夸成高档产品可能是 Sun 的得意之作。Connection Pool 在 Borland 的 BDE 中早就有了，Microsoft 从Borland 偷学来,加在 ODBC,DAO,ADO 中，但是 Borland 和 Microsoft 从来没有把它当作什么高技术来宣传。只有Sun 大肆宣传Java 中的Connection Pool有多么好。明眼人一看就知道，Borland 和 Microsoft 的Connection Pool比Sun得好上百倍。
我觉得大家都上了Sun 过分宣传的当。
Top174楼 jacklondon (jacklondon)
我觉得 Schlemiel (维特根斯坦的扇子) 出这个题目的目的是说，EJB 相对于 JSP/Tomcat 有什么好处，因为如果用 JSP/Tomcat 就能搞定的勉强用EJB 实在没有什么好处。Schlemiel 既然不说话，我就替他给大家提个醒，不要跑题。
Top175楼 Ryoko (阿鸟)
yeah,随便mark一下
Top176楼 zkjbeyond (jigi)
jacklondon(jacklondon) 你知道 EJB 用钝化和激活、组件池做什么？不就是希望性能优化么？既然性能优化不好，为什么不把这些去掉？这样更简单！！
你怎么知道钝化和激活不能优化性能了，你把它们看做垃圾代码，我就奇怪了，你怎么的。
《大家心里都明白，除了CountBean有点有用的代码，其他几个 java 文件都是摆设”，这句话很简单，你都看不懂。这里的 java 文件有：Count.java,CountLocal.java, CountHome.java,CountLocalHome.java,CountBean.java〉》
谁说那是摆设了，你根本不同EJB底层是怎么实现的。乱说。明天等我够200分了开帖找你去。
《BaseEnterpriseBean中垃圾
//不得不写的垃圾代码
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
我说他们是垃圾因为既然我不想写 ejbActivate 代码，我自然也不想写ejbActivate 空函数放在这里摆架子。为什么要写空函数？有何意义？有何价值？既然 ejbActivate 是可写可不写，就不应该放在 java interface 中，因为 java interface 中的函数都是必须要写的。》》
你写过实体bean没有，你找个例子看看，
ejbCreate方法
当客户端调用create方法后，EJB容器调用对应的ejbCreate方法。实体Bean中典型的ejbCreate方法完成如下工作：
l 将实体状态（表述实体Bean的属性字段）插入数据库
l 初始化实例变量，就是对实体Bean的属性字段赋值
l 返回主键
EjbPostCreate方法
对每一个ejbCreate方法，你都必须在实体Bean中写一个对应的ejbPostCreate方法。因为EJB容器在调用ejbCreate方法后接着就调用ejbPostCreate方法。跟ejbCreate方法不同的是，ejbPostCreate方法可以调用EntityContext接口的getPrimaryKey和getEJBObject方法（在前一章的传递企业Bean对象的引用一节讨论过）。EjbPostCreate方法大部分情况下什么事也不干。
ejbRemove方法
客户端调用remove方法来删除实体Bean。该调用会引发EJB容器调用ejbRemove方法，ejbRemove方法从数据库中删除实体状态对应的数据。SavingsAccountBean的ejbRemove方法调用deleteRow私有方法向数据库发送一条DELETE的SQL命令。代码如下：
public void ejbRemove() {
try {
deleteRow(id);
catch (Exception ex) {
throw new EJBException("ejbRemove: " +
ex.getMessage());
}
}
等等等，看看你说的垃圾代码干了些什么。
《Connection Pool 在 Borland 的 BDE 中早就有了，Microsoft 从Borland 偷学来》
那你说java,c#都不是从c偷来的吗。
等明天我够200分开帖找你去。接陋你这个什么也不懂的人。实在是看不下去了。
不懂还要乱说，虽然我是菜鸟，但我知道我的EJB比你懂的好多。
Top177楼 Schlemiel (维特根斯坦的扇子)
to zkjbeyond(jigi)：
public void ejbCreate() throws CreateException{ }
public void ejbRemove(){ }
public void ejbActivate(){ }
public void ejbPassivate(){ }
public void setSessionContext(SessionContext ctx){ }
每次都写这些和业务无关的东东，你不会觉得烦吗？那我觉得你缺乏程序员的一个重要美德——懒惰。在EJB 3.0里面，session bean会是这样：
@Session public class CalculatorBean {
public int add(int a, int b) {
return a + b;
}
public int subtract(int a, int b) {
return a - b;
}
}
（http://www.theserverside.com/news/thread.tss?thread_id=25779）
EJB最大的一个问题就是太麻烦太笨重，3.0会让它变得更好用。与业务无关、只与生命周期有关的那些方法，对于程序员来说的确是没意义的，就应该交给编译器或者容器去做。
Top178楼 samplerliu (sampler_liu)
我觉得有好处，以后你去当个高的工程试师。
Top179楼 jacklondon (jacklondon)
to zkjbeyond(jigi) ,
我强烈推荐你到中小学进修语文半年，自己动手编程半年，买三本以上100元以上外国人写的2003年后出版的EJB书看半年以上，关于EJB中为什么要用组件池看一个月以上，然后再来这里讨论。
关于 ConnectionPool, 我的意思是 Borland 和 Microsoft 都没有把它当作一回事儿，也压根儿不像去宣传它。Sun 弄了一些 ConnectionPool 接口(Sun 好像没有写过 ConnectionPool 代码), 离 Borland 和 Microsoft 的ConnectionPool 水平相差很多年，居然大肆宣传，让我看不懂。这可能与 Sun 董事长的性格有关。我并没有反对开发工具互相模仿。
也请你不要在在这里贴一些最基本的life cycle了，没意思。
Top180楼 bobopig (波波猪)
最近因为公司业务的需要 一直在学习EJB 也在不停的实践 以前在做web方面的开发没有太接触EJB，其实我觉得ejb当中的BMP方式有些当年直接用JSP上面的javabean的影子，至于CMP，的确它省了很多开发者的事情，但是作为编程的人，我总是希望把一切细节都在我的控制之下，太多事情交给容器，象CMP这些把方法的实现，事务的管理统统都交给容器，在开发过程当中让我感觉很没有底，个人觉得看过BMP再学习CMP 会比较容易理解EJB，说实话，初看EJB觉得云里雾里，不知道为什么要这样，只能跟着去先记下再说，也许对它了解运用都不是很深刻，目前我的感觉是EJB在web应用当中有点古弄玄虚的感觉：） 个人感觉 不要拍砖头
Top181楼 javaprogramlover (我最看不起你们这些灌水的了。一点技术含量都没有)
只有硬件上的阵列才可以发挥它的威力！
Top182楼 jacklondon (jacklondon)
我来分析 EJB 的发展历程：
1、Sun 发布 EJB, 声称 EJB 功能强大，对于企业级应用可以加快开发速度。Sun 建议根据业务做成做个 Bussiness EJB Server 安装在不同的服务器上。 Java 迷们蜂拥而上。
2、Java 迷和 Java 专家们很快发现，将 EJB 做个 Bussiness EJB Server 安装在不同的服务器上，有两个问题：一，经常出现有的服务器忙得要死，有的闲得要死，资源不能充分利用。二、做成产品时，安装程序，文档都要做多份，麻烦。因此众多Java 专家们纷纷建议，把所有的 Bussiness EJB Server 做成一样，做成服务器集群，可以避免这两个问题。
3、Java 迷们将 EJB 应用程序(B/S和C/S) 开始做成集群。没有必要作集群的，专家们建议不要用 EJB。
4、Java 迷们发现由于 Web Server(Tomcat或者其他) 的CPU和内存负担相对于EJB Server来说，是小菜一叠。于是把 Web Server 和 EJB Server放在一台服务器上，多个同样的服务器组成集群。
5、Java 迷们发现，既然Web Server 和 EJB Server放在一台服务器上，JSP/Java application 调用同一台计算机的 EJB, 似乎没有必要用 remote 接口，于是 Sun 在 EJB 中增加了 Local 接口。
5、Java 迷们发现，Tomcat/JSP 也可以做集群，Database server 之间也可以很容易数据同步，并且性能比 EJB Server 之间数据同步好，这样无论 B/S 还是 C/S 应用程序做集群，都可以不用 EJB。
6、很多Java 迷们开始将很多 EJB 应用程序改成 Tomcat/JSP+JDBC, 或 Java applicatin+JDBC，放弃使用 EJB。只有在不同公司的 Java 软件需要数据交换的时候，才用 EJB。然而这种需求用很多其他技术可以解决，包括 RMI。EJB 面临危机。
7、Java 迷们发现，JDBC driver 在 close connection,result,preparestatement 的时候，即使没有错误也要写大量的 try catch，不爽。于是兵分两路，一路以 apache 为代表，在 JDBC driver 外面写一个 JDBCUtil, 加入不需要 try catch 的 closeJDBCConnection, closeJDBCResultSet, closeJDBCStatement，这样可以在程序中少些很多 try catch。另一路以 Hibernate 为代表，既然 JDBC 不好用，我们就写一个好用的替代它。
8、Sun 发现情况不对，于是宣布要开发 EJB 3.0，希望挽回局面。但是情况不容乐观，Hibernate 对 EJB 可以说是痛恨之极。Sun 任重道远。
我觉得这是国外的 EJB 发展过程。至于国内，大部分还处于第一阶段。努力啊，兄弟们！！
Top183楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
简单说你对J2EE的了解少得可怜，自以为是的分析太多，没办法一一驳斥了。不懂的东西你可以不开口，没人当你是哑巴。
Top184楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子) ,
不好意思，我认为你最多处于第二阶段。
Top185楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
你爱怎么说都可以，我也绝对没办法说服你，原因我就不说明了。
不过我觉得这样不好玩，也没什么意思，也许你觉得有意思吧。
Top186楼 yaray (雅睿,生活在别处)
看完全帖,个人觉得jacklondon(jacklondon)所说的不无道理.
总之一句话,一切从简.
简单到像用Windows一样,拿着鼠标乱晃,像傻瓜一样(尽管我也是其中的傻瓜之一). ^_^
Top187楼 jacklondon (jacklondon)
to zkjbeyond,
你在我的文章：
Java 的JDBC 数据库连接池实现方法 ，http://www.csdn.net/Develop/read_article.asp?id=21140 上面发表的所谓很好的连接池代码我已经把它批了一通。我希望你批评别人之前先把别人的东西看懂！
Top188楼 ostriches (一村又一村)
这里的火药味好象太浓,帮忙顶下!!!
Top189楼 asklxf (xuefeng)
"Java 迷和 Java 专家们很快发现，将 EJB 做个 Bussiness EJB Server 安装在不同的服务器上"
我还没有发现有公司会把一个应用装在一台weblogic+一台websphere上，想不出有什么理由来维护两种app server
"Tomcat/JSP 也可以做集群，Database server 之间也可以很容易数据同步，并且性能比 EJB Server 之间数据同步好，这样无论 B/S 还是 C/S 应用程序做集群，都可以不用 EJB"
的确数据库可以集群，但是那是在持久层的集群，业务层除了ejb用javabean能集群？
"另一路以 Hibernate 为代表，既然 JDBC 不好用，我们就写一个好用的替代它。"
这是封装，不是替代，hibernate可以替代entity bean倒是真的，而且更加灵活
以上仅供参考。
Top190楼 anders0913 (小憩的神)
如果客户看到它的点击迟迟不见反映，你的所有努力立刻over，客户才不管你的设计多么OO。
Top191楼 Schlemiel (维特根斯坦的扇子)
to anders0913(战神)：
你用这句话想说明什么呢？TheServerSide.com是使用EJB的典范，它让你“迟迟不见反映”了吗？
一个OO的设计使你可以更准确地找到性能瓶颈，更好地优化。对于一个设计乱七八糟、代码被四处copy的程序，你要是有办法优化它的性能才怪。
Top192楼 jacklondon (jacklondon)
“我还没有发现有公司会把一个应用装在一台weblogic+一台websphere上，想不出有什么理由来维护两种app server”---误解了，我说的不同服务器，是指硬件，不是指 app server。
“但是那是在持久层的集群，业务层除了ejb用javabean能集群？”---我不明白你说的是什么意思。我只知道，ASP/PHP/JSP 都可以做集群。
“这是封装，不是替代”----对于最终程序员来说，以前用JDBC,现在改用Hibernate ，那就是替代。
Top193楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子),
EJB 性能调试并不容易。现实生活中慢的 EJB 程序很多，国内会调EJB 性能的高手并不多。
Top194楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
就像你以前说“Linux/Unix程序员不多”一样，这次你想说的其实是“国内会调EJB性能的高手，你认识的不多”。
Top195楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子) ,
我不想和你争蛮理。 Windows 程序员比Linux/Unix程序员多是大家都知道的。Linux/Unix 网站上都把 Windows 的流行原因归为 Windows 的应用程序多，既然Windows 的应用程序多，开发人员自然也多了。
至于 EJB 的性能比 JSP 差，想也想得到，EJB 调用 RMI, 保持集群之间的数据同步，都需要执行大量的代码，比直接 Call Java bean 会快？建议你找几本最基本的 EJB 书看吧。
性能测试中，ASP 很早就达到了每秒 870 个页面(参考：http://www.freelamp.com/new/publish/1015136602/index_html), 你能把 EJB 性能调到每秒 870 个页面吗？国内有几个人能够？有一百个吗？我不相信。
随便在国内找100个EJB项目，随便在国内找100个JSP项目，进行性能比较，平均下来，我相信JSP项目会更快。国内达到了100个EJB项目有20%有调EJB性能的高手吗？没有！！
Top196楼 zkjbeyond (jigi)
下面是引用自 jacklondon(jacklondon) 我已经退出讨论
EJB bean 之所以要做组件池，原因在于 java 的一个大硬伤：new 操作非常的慢，相当于1000倍以上的赋值语句。在大多数性能优化的书中，都会提到，尽量避免 new；特别是需要长时间运行的程序，最好要把需要的 object 缓冲起来。这就是 EJB 组件池的设计由来。但是EJB 组件池只是略微改进了性能，而且大多数 EJB server 在这方面都做得不太理想。Apache web server 有一个内存池，比较好，EJB server厂商需要多多学习。
Top197楼 l7980 (天使抛弃的小猫)
分、分
Top198楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
这就是我一直不太想跟你讨论的原因，你根本就缺乏必要的常识。很多在我看来是理所当然顺理成章的事情，到你这里就必须重新解释一遍，而且解释了你还不一定相信。没有必要的背景，所谓讨论就变成了鸡同鸭讲。
比如说，什么叫“每秒870个页面”？在我看来那仅仅是个Web服务器集群的问题。我用一台WebSphere服务器就可以支撑300个并发访问，如果我用10台服务器集群，你说每秒1000个页面又算什么呢？这跟我的程序写得好不好有关系吗？我看只和客户肯出的钱成正比。
更有趣的就是“把 EJB 性能调到每秒 870 个页面”。EJB是一种服务器端业务组件，不是面向展现的，所以也没有“页面”的概念——啊，我多么希望进来讨论的人至少能够有必要的常识或者必要的谦虚态度。同样，EJB天生支持集群，不需要任何额外的配置。所以你的这种所谓性能比较，实际上是在比服务器的性能，跟程序毫无关系。
“至于 EJB 的性能比 JSP 差，想也想得到，EJB 调用 RMI, 保持集群之间的数据同步，都需要执行大量的代码，比直接 Call Java bean 会快？”——请考虑每秒2000次并发集中在一个服务器或者负载均衡到10台服务器的情形，我可能不知道哪个会更快些。如果不需要考虑伸缩性、灵活性，你完全可以用汇编写一切东西，那可能是最快的。
“国内达到了100个EJB项目有20%有调EJB性能的高手吗？没有！！”——我完全相信你的话，你认识的人里面没有，你知道的人里面没有。这不是在置疑别人的水平，仅仅是在置疑你自己的眼界而已。
Top199楼 Schlemiel (维特根斯坦的扇子)
顺手再指出一个明显的逻辑错误：
“Linux/Unix 网站上都把 Windows 的流行原因归为 Windows 的应用程序多，既然Windows 的应用程序多，开发人员自然也多了。”
如果你可以首先证明“普通用户使用的家用应用程序 等价于 应用程序”的话，那么你的上述推理无疑是成立的。
Top200楼 jacklondon (jacklondon)
普通用户使用的家用应用程序又怎么啦？Winzip 的作者比你我赚钱多多了，水平也不见得比你差。
Top201楼 liuxiaobo8590 (青云)
EJB没有用过。先座下来听听。
Top202楼 dmhorse (dmhorse)
有意思
不过我不懂EJB
老板要的是快速
根本不考虑分布式,用N台server顶就算了
Top203楼 Schlemiel (维特根斯坦的扇子)
to jacklondon(jacklondon)：
请注意，我主张的观点是“家用软件不代表全部应用程序”，而不是“家用软件不赚钱”。我的观点是家用软件在所有应用程序中不占大多数，因此由“Windows上家用软件多”推不出“Windows程序员多”。至于家用软件是否赚钱，那不是我在这里关心的。
你的这次转移话题给我留下了一个不好的印象。如果你是错误地理解了我这么一句简单而明了的话，我不得不怀疑你的理解能力。如果你是发现无法驳斥我的观点而故意转移话题，你说我该怀疑什么？
Top204楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子) ,
1。请教，“Linux/Unix 网站上都把 Windows 的流行原因归为 Windows 的应用程序多，既然Windows 的应用程序多，开发人员自然也多了。”这里提到了“普通用户使用的家用应用程序”吗？是你在转移话题，我可没有说“普通用户使用的家用应用程序 等价于 应用程序”，我只不过看你有点看不起家用应用程序的样子，其实它们中间优秀的软件极多，优秀的程序员也极多。
2。书店里面 windows 编程的书比 linux/unix 多，书店是根据用户购买量来决定多进 windows 编程的书还是linux/unix的；“Linux/Unix 网站上都把 Windows 的流行原因归为 Windows 的应用程序多”，难道 windows 的程序员反而少？招聘网站上面的windows 职位也比linux/unix ，难道 linux/unix 都不招人了？怪！
3。请给出一个你认为linux/unix 程序员比windows 多的证据！！
Top205楼 holder (明年俺就毕业了)
好像跑题了........
Top206楼 netpirate (海盗)
板桥里人 有两篇文章有说，大家有空可以看看。
附：
为什么要使用EJB？
http://www.jdon.com/artichect/whyEJB.htm
关于对J2EE几点误解和错误认识的澄清
http://www.jdon.com/trainning/net_j2ee.htm
Top207楼 gree001 (253)
天，看了半天，原来快吵架了，不过菜鸟偶还是学到了一些东西的。。
谢谢
Top208楼 fcy241 (飞扬)
浪费时间^-^
Top209楼 Schlemiel (维特根斯坦的扇子)
to netpirate(海盗)：
你就别再拿那篇文章出来扫板桥的面子了。要么你可以试试，左手拿那篇《为什么要使用EJB》，右手拿刚出来的EJB 3.0新特性列表，问问板桥有什么意见，看他会不会脸红。板桥提出的使用EJB的5点理由，至少有4点是站不住脚的。
>>Web+EJB能组成真正的多层结构
如果这是在暗示基于POJO的体系结构就无法清晰地呈现多层结构，那就完全是在搞笑。我不想再举Spring之类的例子，这些例子已经举过太多次了。EJB 3.0的组件是怎么做的？全都是POJO，仅仅在annotation上有区分。EJB 2.x所做的只是侵入业务组件的接口，我相信这不等价于“体系结构的清晰”。
>>EJB组件能提供真正的可重用框架
更加彻底的搞笑。仍然不用说其他的，只举一个例子：假设SessionBeanA需要使用SessionBeanB，它就必须通过JNDI去查找到后者，就像这样：
SessionBeanBHome homeB = (SessionBeanBHome) ctx.lookup("application1/homeB");
SessionBeanB beanB = homeB.create();
请问，这样的代码出现在SessionBeanA里面，这个组件还能叫“可重用”吗？如果你直接把这个组件移植到另一个application，这样的JNDI查找还能用吗？EJB 3.0已经将容器改为使用Dependency Injection，足以证明EJB 2.x的所谓重用能力连EJB专家组自己都不满意。
>>EJB提供了事务机制
不妨去看看Spring提供的声明性事务。
>>CMP独特的优点
我看CMP“独特的优点”包括：不允许继承，不支持动态查询，不支持非对象查询，不能直接new出来使用，等等。CMP不仅不能很好地描述业务领域模型，反倒阻碍了面向对象的设计，这能叫一个好的O/R Mapping工具吗？去看看EJB 3.0的CMP规范，完全跟Hibernate一模一样，实体都是POJO具体类，允许继承，允许new，持久化管理器可以动态执行EJB QL，可以直接执行SQL……用hani的话来说，这是Gavin King的大胜利，他让EJB专家组自己抽了自己的嘴巴。你倒好，还非要提出这篇文章来，让板桥也抽自己一个大嘴巴。
>>不要再被TSS那些狂热的开源先生误导
>>作为专业的J2EE程序员，按照J2EE标准去学习去行动
现在好了，看看EJB 3.0的样子，看看板桥先生紧跟的“J2EE标准”给了他什么吧。当他正在热火朝天地鼓吹EJB 2.x、试图证明“EJB的沉重有其价值”时，EJB专家组彻底抛弃了他。EJB 3.0的容器像Spring，CMP像Hibernate，这恰好证明：在这场轻量与重量的争执中，正是Rod Johnson、Gavin King这些“狂热的开源先生”最终成为了胜利者，现在是Sun和J2EE标准在跟着他们走。当Hibernate拿到Jolt大奖，当JDO 2.0和EJB 3.0都拼命地向Hibernate靠拢，我想问，到底谁误导了谁？
做J2EE的同行们必须知道，Sun不是微软，J2EE的Open Source社群也不是Mono之流扶不起的阿斗。要想保证自己的学习投资不被浪费，你就必须保持对技术趋势的警醒，你就必须每天关注“TSS那些狂热的开源先生”在说些什么做些什么。因为，很可能就在明天，他们就会影响整个J2EE社群（不管是民间的、自发的还是官方的、标准的）的走向——实际上Rickard Oberg早就让我们见识过这一点，可惜这里的太多人经验和阅历都太浅，他们甚至不知道Rickard Oberg做过什么，Gavin King和他的Hibernate只不过把以前上演过的戏码再翻拍一遍而已。
Top210楼 asdmonster (呆鸟四号)
Schlemiel(维特根斯坦的扇子) :
首先感谢你给的那个链接。
ejb3.0带来的观念是震撼的，但是在很多观点上，我觉得，比起你，我的感觉要悲观得多。
首先不讨论mono是不是扶不起的阿斗，我想即使是没有对vb,asp，net等有深入的学习，也能看出这些Microsoft的产品的极其傻瓜化，当我们的java社区的趋势是轻量级的时候，我们能轻量得过Microsoft?
其次是java社区，从来没有人怀疑这个社区里面的人们的能力，但是也同时有很多人指出，如果将来有一天这个社区崩溃，压力不来自于Microsoft，而是社区本身。这里面有很多天才，也仅此而已。所有的技术论坛中，技术更新最快的是java,吵得最凶的也是java，和c++吵，和.net吵，java的这个派别和那个派别吵。“一个又一个的开源分裂了我们的社区”！
最后回到我们的主题：看了ejb3.0你能给ejb一个下一个严格的定义吗？反正我是一片思维混乱。如果ejb的定义仅仅是运行在容器里的O/R mapping工具，那么hibernate是做什么用的？仅仅是因为运行的本地环境（local envirment）的工具？ejb真的仅仅让IBM多卖几台服务器？下个大胆的赌注：hibernate之流和ejb3.0哪个先死？
在性能上，JAVA再怎么快也快不过C/C++(理论上的可能都没有)，开发效率上比不过.NET，稳定性方面，Microsoft没有高端产品的原因主要在于win os本身就没有7*24能力，如果有一天MONO在unix上获得成功呢？JAVA留下的还有什么？难道我们真的只能指望MONO最终是个付不起的阿斗？
《大话西游》里面的四个差役死前是这么说的：当初不如做山贼。难道将来我们要说，当初不如学.net，当然，那时候可能我们都退休了。
Top211楼 jacklondon (jacklondon)
很正常。EJB 1.0 出来的时候，大家都说棒极了；EJB 2.0 出来的时候，大家都说EJB 2.0棒极了，EJB 1.0差极了；EJB 3.0 出来的时候，大家都说EJB 3.0棒极了，EJB 2.0差极了。。。。。。。
Top212楼 jacklondon (jacklondon)
to Schlemiel(维特根斯坦的扇子),
"每秒870个页面"是单个服务器的性能指标，pages/second 是性能测试中很基本的指标，你不懂就算了。如果你认为10台 EJB server 的总体性能比 1台 jsp server 好，就认为EJB 性能好，我实在是佩服得紧！
Top213楼 sean_gao (大胃 http://blog.csdn.net/sean_gao/)
看了半天，不想参与到EJB好与不好、该用与不该用的讨论中。一方面，我觉得具体问题要具体分析，杀鸡用什么刀？蚊子用什么打？另一方面，不怕大家笑话，我觉得我的EJB经验还很欠缺。
有关解释型（VM/Runtime环境下运行的）代码能否在性能和速度上超越传统的编译型代码的问题，说说我学习.NET后的一些体会：（垃圾收集开发速度什么的我想知道的人太多就不提了）
我们按传统的方式比如C/C++写代码然后编译的时候，生成代码一般都是针对一个特定类型的平台，如INTELx86，这个时候编译器只能根据一定的标准生成兼容所有x86平台和特定OS的代码，对最终需要运行的具体环境细节，如是否使用了支持某种新技术的软/硬件、这个代码是否还有可以进一步优化的地方等，一无所知。
而类似.NET环境下写的托管代码，我们写出来的代码被编译成中间代码，类似Java的byte code，这个中间代码复制到具体机器后，JIT可以根据具体的运行代码的机器对代码进行编译和优化：在编译时，编译器可以检测到机器的具体特性如是否为某种型号的CPU，如果是，可以针对具体的指令集产生更优的native code，而不是为了兼容放弃更好的指令集；对具体的代码中的某些表达式可以直接生成结果，如内存大小、CPU数量、操作系统版本等，而不必每次都做计算。在执行的过程中，profiler工具可以根据代码执行情况发现和记录"热点"，然后再作专门的优化工作重新编译。
当然，为了提高速度，Java和JVM需要做的改进工作还有很多很多，不过大家可以就此发挥一下想象力，是不是这样发展下去解释型代码会最终在执行速度和性能上超越传统代码呢？
Top214楼 esunboy (天使联盟)
今年的第一强贴， 基本上同意扇子的意见。
发觉大家回贴时可以更客观一点，说话也不要太激了。
我刚学ejb， 进来学习， 呵呵！
Top215楼 Schlemiel (维特根斯坦的扇子)
>>很正常。EJB 1.0 出来的时候，大家都说棒极了；EJB 2.0 出来的时候，大家都说EJB 2.0棒极了，EJB 1.0差极了；EJB 3.0 出来的时候，大家都说EJB 3.0棒极了，EJB 2.0差极了。。。。。。。
确实很正常。我们总是寻找当前最好、最合适的技术，并略微展望将来的趋势。如果你想一劳永逸地找到一种永远正确、永远最好的技术，也不是没有，那就是什么都不做。我相信大家在讨论一个技术的“好”与“不好”时，心里都明白我们是在对当前世界上各种可选方案进行比较。如果你连这个语境都不明白，这个讨论就无法进行了。
重复一遍：讨论必定有一个共同的背景语境。你可以不承认这个语境，那么你的所谓“讨论”实际上就全是废话。
Top216楼 Sheepy (-[J.2.E.E]-)
我从学习者的角度发点声音。
大家都一直在说EJB、EJB，我怎么觉得应该分开来说？session bean和entity bean完成的是不同的工作啊，还有message driven bean，为什么要统称EJB并进行评价？应该分开评价嘛！比如要拿Hibernate来比，只能和entity bean比较，因为它们做的是一样的事情。和“EJB”进行比较是不对的。
应用分层和ORM确实不是选择EJB的原因，然而对于一个学习者来说，要学习这样的思想，可以从EJB开始，因为它是Sun的标准，J2EE从JSP、Servlet一路学过来思路也比较顺，也有大量的学习资料。
Top217楼 alienbat (亡灵法师)
来随便看看，并灌水。
EJB 3.0学习了诸多轻量级解决方案，应该变得更加完善和易用吧？
Top218楼 arg (雨隼)
来听课。。。。
正在学ejb，感觉太繁琐了，调试极端缓慢，
现在这个项目为了避免在调试中重起动 was，不惜违背设计模式在jsp中掺杂了大量的业务代码，埃~~~~
Top219楼 tigerlg (tigerlg)
偶也说顺便2句
ejb在处理群集，和事务的复杂程度还是比较好。关键看你怎么设计它
我以前开发一个项目用ejb做的，感觉很不错的，结构非常清晰，层次分明。
Top220楼 lixinlong12 (李为)
使用EJB最大的好处在于它的可扩展性，其实这就是分布式的优点，它不同其它框架在于EJB是一个规范，其具体实现由各个厂商完成，所以它可以deploy到不同的application server上。
但是如果你的项目规模不大的话，我不推荐你使用EJB，你可以选择JDO，Hibernate作为你数据库访问对象。
Top221楼 k2008 ()
学习ING
Top222楼 clarck3000 (j2ee)
我支持ejb，如果说他没用，是因为你不懂。Corba有没有用？
通过ejb j2ee技术，可以很好的实现复杂的系统，他是比较笨重，但同时又有很强的安全性，强壮，可移植。
他抬灵活了，不会用的人自然就多了
Top223楼 bistar (I‘m Marvin.)
收藏
Top224楼 OptimismNo1 (梧桐雨轩)
Top225楼 successlikun ((******))
作一个分布式的系统就能体会到EJB的好处了，在EJB容器下不用考虑分布式的通讯。
Top226楼 dropship (光荣与梦想)
大家继续啊，我来学习
Top227楼 tyrone98 (林林)
我用EJB的开发总结EJB的几个好处有：
1.事务自已管理。
2.能够很方便的群集。
3.很多人都说EJB效率低下，尤其是实体BEAN，我的项目都是使用Weblogic的，经测试没有此类问题。
4.企业业务逻辑放在EJB上，网页工作者与业务逻辑的实现者可分开，但是可能需要很多沟通。
5.表现形式多样，你可以用C/S , B/S方式架构。而业务逻辑不用改。
6.可先产生测试程序，用IDE工具可以很容易产生EJB的测试CODE，不需要网页工作者做完才做，当然JSP中用javabean的话也没有这种问题。
坏处是:
1.调用不方便，有时你一个业务中会发生EJB调用EJB，写起来没有javabean调用方便。
2.程序量加大，需要在调用EJB中也加一套类库，当然也可以不加，但是用起来很不方便。
3 调试不方便，需要先部曙，在调试，机器慢一点的话，会白花很多时间。
你如果使用EJB，最主要的一点是分离你的业务逻辑与界面。这会花去你很长的时间，分的不好的话，白花时间，写出来的程序效率又低.
Top228楼 power_zh (鬼魂释放者)
学习
Top229楼 cngis (集思)
哈... ...
Top230楼 dropship (光荣与梦想)
呼唤高手
Top231楼 ()
用户就是上帝，需求决定一切！我们的所有理论都是为实践服务的。
个人观点：Ejb在中小项目中少用为好。
Top232楼 zkjbeyond (jigi)
这帖子还这么火啊！
现在正在研究WebGis。
Eris的ArcIms，基于web Server 的中间件。整个基于java的中间件。棒
我觉得要想知道到底什么时候用EJB,首先把中间件这个概念弄清楚。
Corba IIOP/RMI JavaRMI 分布式系统 中间件 这些关键词要明白。
MS在分布式系统中 为什么选择WebService.
Corba和WebService哪个速度更快啊。
Top233楼 imagex (<<<<<<★>>>>>>)
mark
thx
Top234楼 javavc (炼狱)
ejb的性能是它的一个软肋,也是别人攻击/嘲讽它的着力点.但我想说的是:作为一个中小项目,它所涉及到的表同样也不是特别的多,如果硬要说是ejb影响了整个项目的性能,我个人认为这有些偏颇.性能问题是跟你的整个构架以及你所用到的技术等等各个方面都有关系.假设有一个项目有50个表,你能说项目的性能就是因为用了ejb,就使得项目的整体性能下降了50%?
我做过ejb的一个中型的项目,有一段时期,性能确实比较差,于是就有人抱怨说ejb怎么怎么不行,为什么不用jdbc或者其他的技术实现功能?呵呵,我觉得很搞笑,说白了就是哪个什么什么不出怪茅坑.后来项目组的两个技术骨干花了很大的功夫去查找影响性能的原因,对服务器的配置,代码的结构做了很大的调整,最后让大家得到了满意的结果.其实网上对于设计模型也有很多的方案.我看见不少的模型是ejb的sessionbean+hibernate+struts. ejb的性能问题是由entitybean引起争论的,而hibernate却能解决这个问题,至于sessionbean性能上并不是很差,而且提供了事务管理的功能.
总之,我想说的是ejb本身的性能问题确实存在,但在整个项目中,从大局来看,性能的问题很大程度上跟你的系统架构整体相关的.不能片面的把所有的问题都归咎于某一个技术.另,ejb写起来确实很麻烦,不过ejb3.0在简易性方面做了很大的改进.ejb还是值得大家去学的.
Top235楼 lostmyway (自愚自乐--fool myself,then,feel happy)
这个贴应该摆在CSDN主页！
Top236楼 dropship (光荣与梦想)
等待中
Top237楼 cnham (好好工作每一天)
mark
Top238楼 daomei (伤心渔夫)
大家都是学习嘛，看不起某些人借贬低别人来抬高自己,最讨厌的就是这种人
Top239楼 shenzhili (li)
进来学习一下
Top240楼 zyfdanny (黄金分割点)
mark
Top241楼 ff2004 (风云子)
mark
Top242楼 cbhyk ()
mark
Top243楼 gameboy999 (-‘_‘-)
有了Jbuilder,写EJB真的好简单，部署也不是太难，用起来也有testsample代码参考，
可是，ejb应用还是有不少问题
1。对于我们中小项目来说，javabean实在是比EJB好用
2。经费要求，有ejb容器都比较贵，客户不一定同意你用jboss对不对？
3。ejb对于大部分程序员都有门槛，怎样调试，怎么维护都是个问题，更不要说对部署人员的高要求了。（系统部署出了点问题，都很难知道究竟是哪部分错了）
4。层次并不是分得越多越好，一个中等项目，又要用servlet container,又要用ejb container，还要用web service，在加上前面struts,后面hibernate,把本来容易的事情变得很难，因为很多事情本来就很难判断它究竟属于哪个层。
Top244楼 asdmonster (呆鸟四号)
用adsl上网，居然能打开这个帖子，不容易，留个脚印
Top245楼 danieltang (蓝色激情)
其實意義不大
Top246楼 ()
就是搂主的火气大了一点
希望不是rpwt
Top247楼 tijichen (笑起来像狗)
同意gameboy999的观点，用EJB一是性能问题，二就是部署，三就是会用EJB不一定等于用好EJB，很多程序员号称一月搞定EJB，如果让这种程序员做EJB项目，结局肯定是失败，EJB不算太难，但要理解其精髓并能灵活运用也需要时间、经验的积累呀
其实EJB的思想的确是很值得借鉴的，但是实际项目中是否要用的确需要项目开发者本身好身掂量一下，除了自己用JAVABEAN封装，hibernate、ibatis会更适合做中小项目
Top248楼 kuanda (鱼)
up & study
Top249楼 shocking2001 ()
众说纷纭，看来还得根据实际的情况过来学习运用
Top250楼 sailing27 (许愿)
难得一见的好帖。
顶
听说EJB3.0快出来了。有很多地方都很像Herbernate。而且对很多地方作了简化。期待中~~~~
Top251楼 shadowDLL (Tomorrow is another day！)
初学者，关注中
Top252楼 007JavaKing (乖乖咙的咚)
这么好的贴怎么能没有我？JAVAKING
Top相关问题
- 给大家一个锻炼脑子的机会：EJB有什么好处？
- 如何在一个WEB应用中调用一个已经部署好了的EJB？
- 我爱上了一个女孩，大家看看我有机会吗？
- 大虾：tty的作用是什么，一个process为什么要关联一个tty?
- delphi中，创建一个dll应新建一个什么呀
- 有什么办法在一个过程里调用另一个过程？
- 什么SQL可以在一个表中插入一个新列
- 在定义一个struct时加一个typedef 有什么用处啊？
- 在vbscript中用什么函数可以实现从一个网页导向一个网页
- 我是一个delphi初学者~~~请教大家一个菜鸟问题~
网站简介－广告服务－网站地图－帮助信息－联系方式－English－问题报告
CSDN北京百联美达美数码科技有限公司 版权所有 京 ICP 证 020026 号 CSDN
© 2000-04, CSDN.NET, All Rights Reserved
给大家一个锻炼脑子的机会：EJB有什么好处？ Java / J2EE / EJB / JMS
给大家一个锻炼脑子的机会：EJB有什么好处？ Java / J2EE / EJB / JMS
轻松搞定Eclipse配置(一) - J2EE/EJB/JMS - Java - 编程开发...
Java里采用EJB开发的三个好处
J2EE‘S EJB Technology
EJB
什么是EJB - Java
J2EE 组件开发：会话EJB
开发基于Eclipse+Jboss+Mysql的EJB/J2EE应用系统
一步一个EJB
EJB的七年之痒
EJB的七年之痒
分享Java快乐 -ECLIPSE+HIBERNATE;eclipse+ejb
EJB调用的原理分析
什么是EJB
Springvs.EJB
什么是EJB
提高EJB性能的十大技巧
深入探究EJB应用技术的体系结构
深入探究EJB应用技术的体系结构
j2ee web service开发(五) 把ejb发布为web服务 - 一切从实用出发!...
j2ee web service开发(五) 把ejb发布为web服务 - 一切从实用出发!...
EJB 最佳实践
Spring Vs. EJB 3.0