给大家一个锻炼脑子的机会：EJB有什么好处？

就是分布式，自己去写rmi麻烦。如果都放在一个jvm里实现了，就没有必要用ejb。

话不能这么说。很多人知道我并不推荐EJB，我是轻量级方案的推崇者。但是EJB作为Sun非常重视的一种方案，它仍然有它自己的优点。作为一个称职的开发者，我们有必要丰富自己的工具箱。没错，你今天可以直接在JSP里面写所有代码，在特定场景下这是合适的做法。但等你的客户成熟起来，等他们的需求复杂到一定程度，你愿意继续像个傻瓜一样在JSP里面写所有代码吗？

只能听,没有用过,不过好多人说还可以,只是对其中的实体bean有颇多微词

觉得要实现分布式 EJB还是首选的不知道其他兄弟怎么想的

只做过会话bean,我只知道我省了管事务的心,其他还真不知道

听说过这么一句话，“EJB是sun彻彻底底的谎言”。呵呵！

偶用过一段时间，笨重。尤其是entity bean 即使用CMP方式也不灵活
感觉没什么实际用途。主要是想不出有什么必要非要这样做的理由。
开发繁琐（编译部署缓慢），维护困难。它的分布式功能，在绝大多数项目中好像用不上。
而MVC的概念，不用EJB也可以实现得很好。我觉得没接触的同志，了解一下就可以了。
有这功夫不如钻研下 strut Hibernate 等东西实用些。

我赞成usabcd的说法，但是安全性确实不错

1.容器提供了事务管理
2.学习资源较多，开发工具也很多
3.ejb有很多商业公司支持

1.容器提供了事务管理
2.学习资源较多，开发工具也很多
3.ejb有很多商业公司支持
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
这些说得都没有错，十分的有道理，不过，衣服只有穿在身上才感觉合不合身。
如果你拿它做过几个正规的中型以上的项目，如果还对它的有点如数家珍，赞不绝口，
那我就没话说了。事务处理它是提供了，但算不上是个什么大不了的优势，大部分的项目，仅靠数据库本身的
连接的事务处理就足够了。只有在跨数据库操作时才用得上。这种情况很少，即使有也可以
手工写代码搞定。
学习资源多并不见得开发效率就高。不用它用其他方式资源更多，做过项目就会有切身体会。
至于商业公司支持也事另外一码事了，我不用EJB照样可以跑在商业公司的 App Server上,
而且性能更好。对了，开发费时费力是一方面，
EJB还有一个比较重要的问题，性能问题。如果一个大的系统有数百乃至上千个表，
如果用Entity Bean，试下看看，嘿嘿，仅仅光挂上100个 Entity bean 还不要说业务逻辑Session Bean
app server就很辛苦了。（免费的jboss挂到30个都吃力），这个也许算EJB的硬伤了。
不知有用过的兄弟能否讲讲性能方面的体会啊。不过我个人的体会，搞EJB可以让人在开发的过程中开始思考一些系统架构方面的东西：
比如开发模式，软件分层与组件复用等。这些感觉都要经过一段时间的积累而成。

我感觉ejb为了让你全神贯注的关注你的客户的需求，而不是关注程序！！程序员的精力毕竟有限，如果想更好的应对将来的大规模开发，你就必须更加关注需求，关注模式，而不是关注程序的安排

可能过几年才能体现出优势来吧，等容器更加成熟稳定，速度更加快，不在被大家指责的时候，EJB就会体现出它在分布式方面的优势来。所以我觉得它的前景也许不错，现在……

在我看来EJB的集群能力是无与伦比的。如果需要应用服务器级的集群，EJB几乎是唯一可选的方案。当然集群本身就很有讲究，如果在性能瓶颈是在web层或者数据库层（实际情况往往是这样），应用服务器的集群就毫无意义。application clustering，我认为是选择EJB的第一理由。大家请继续。我相信很多人做过EJB开发，应该可以从实践经验中找到一些EJB的长处。

其实EJB本没有什么好处，用的人多了，便好象有了很多好处呵呵

EJB 是用在分布式环境下面，如果有多个 server 多个 database 才用。只有一个 server 一个 database 没有必要用，这是很多 EJB 经典书籍中都讲的，可惜很多人都不注意。
一个 server 一个 database 完全没有必要用 EJB.
实际上在 ASP/ASP.net 编程中，多个 database 情况由 database 自己做数据同步，主流数据库都能做。多个 server 由操作系统做负载平衡，这个需要 Windows 2000 advance server 或者 Redhat enterprise server 。基本上，对于编程者来说，只要安装正常一个 server 一个 database写法写程序，不用懂太多东西。我比较看好这种做法。

实际上，如果没有分布式的需求，用 jsp/servlet 开发即可。以后需要改成分布式，原来的代码又不是不能用。大部分代码都可以 copy , 做少量 modify 即可。
现在很多人在一个 server 一个 database 下面用 ejb, 不懂是为什么，乖乖！！

to jacklondon(jacklondon)：
首先copy and modify的做法是绝对不可取的。你可以根本不用问为什么，重复代码是万恶之源，哪怕你找出一千个理由说服自己“这次的重复代码不会出问题”，最后你仍然会被重复代码狠咬一口。有些事情不一定非要尝试的。
数据库的集群应该由数据库来做，这一点我同意。但是“多个 server 由操作系统做负载平衡”，我可能就要持保留态度。最简单的例子：如果你的business service组件是有状态的，哪个操作系统能在不同的进程之间保证同一组件的状态一致？不用懂太多东西的话，写出来的程序也不会有太多用处，这不是观点，是经验。

关键要大型应用的时候才能看出效果
小的东西没又必要用ejb

斑竹的题目我觉得很恐怖，好像大家都没有机会锻炼脑子，：），
我觉得EJB是面向需求的。

to shmiluwei(井底蛙)：
“EJB是面向需求的”。你觉得这句话说了跟没说有什么区别呢？我觉得没有。纯粹就是一句不痛不痒的废话，而且跟我的问题根本不搭界。EJB到底好不好？好在哪里？我想没人能从你这句话里看出答案。你还不如说“道可道非常道”呢。
从你这个答案，我倒觉得你的确有点缺乏锻炼脑子的机会。

如果表示层（界面）我不用jsp，不在浏览器里操作，而选用application 也就是swing那套东西，使用java web start。那么是不是ejb也将成为必须的选择？？？楼主及各位高手能不能回应一下！

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端口打开吧。

MDB,JMS可以完成很多一般很难搞定的事

我参与一个大型的J2EE项目,我想问问如何设计和优化CMP,这东西真的很慢,
而且设计项目的人也很牛B,J2EE模式和EJB模式都运用的很不错,SessionBean和CMP用的也是本地接口,但操作数据就是很慢.....

老师让我给他做一个用户登录界面
我说我用JSP 给你搞定吧
老师不同意，让我用EJB ，结果到现在我还在东搞西搞，郁闷。不同意楼主的--〉重复代码是万恶之源
坚决反对，什么事物都是有两面性的，没有什么东西是绝对坏的，重复代码在一定的情况下应该就是代码重用，这是软件工程，Java的继承、重载等等所提倡的。

to Schlemiel(维特根斯坦的扇子) ,
你不要断章取义。
我说的“以后需要改成分布式，原来的代码又不是不能用。大部分代码都可以 copy , 做少量 modify 即可”，
意思是 jsp + javabean 代码如果需要升级成 EJB + javabean, 大部分代码还是可以接着用的，特别是 javabean 中的代码，略作修改即可。

to   Schlemiel(维特根斯坦的扇子)
  首先感谢你的提供的信息。虽然我问的离你的题目有点远。希望讨论能增加大家对ejb的更深认识。第一感觉，我以为你会引用Hibernator来说明问题。没想到你提到Spring、PicoContainer等（我对这些基本上没有概念，刚搜了一下看了看，见笑了。）。一个问题总是有很多的解决方案，我们希望选择最好的，最适合自己的。从构架一个系统或者说拉单子角度讲，不可能说现招一批程序员或者花一段时间培训，更不可能给客户去讲Spring或Hessian如何可以替代ejb更好的处理事务问题、分布式问题。这似乎是选择ejb的问题了。
  从某种角度讲，选择了说明他对自己目前状况有一定的选择优势，不知道会不会遗害无穷……

建议 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.

我也不知道ejb是什么东西，但听我同事说它是垃圾。

推荐大家看《EJB编程指南》(Rahim Adatia, Faiz Arni, Kyle Gabhart)，里面关于什么时候用 EJB 有很好的见解。
服务器集群中的 session 问题，建议大家看 JBoss 或者 Weblogic 的文档。基本上变成的时候不用考虑它，这是一个配置问题。
ASP.NET 我建议大家看《ASP.NET 技术内幕》( Stephen Walther )，里面关于服务器集群中的 session 问题有非常妙的讲解。
另外，建议大家同时学习集中技术，这样你才能知道，每种技术的优点，缺点。只学一种，永远达不到这种境界。

jacklondon(jacklondon) 你说的对啊的确许多中小型项目没必要用的EJB,完全可以用M$.NET studio进行快速开发,后期的维护也比较简单,也不需要扩展什么功能. 但是...我想大家知道软件业比较有钱的几个主应该是电信,银行,金融,政府,项目一般投入很大,后期维护升级工作量也很大,如果没有一个优秀的架构平台(比如J2EE),和良好的项目架构设计,我想这样项目到后期维护的时候一定让人痛苦欲绝.... 我想学好J2EE还是很不错的选择,上升的空间也比较大,可学的东西很多....
个人观点,不代表广大群众...呵呵

调试易

给大家一个锻炼脑子的机会：EJB有什么好处？

解决方案 »