Java开发网 - [讨论]到底用不用EJB？

Topic: [讨论]到底用不用EJB？

1.[讨论]到底用不用EJB？

Posted by: muziq
Posted on: 2003-07-16 16:27

看了《Expert One-on-One: J2EE Design and Development 》，深受启发，作者的部分观点总结如下：（括号里面是我个人的感想）
·如果不需要RMI，就不必使用EJB（我觉得这很有道理，如果要考虑性能问题，可以集群，分布式的EJB架构有多大的实用价值？）
·由于容器运行在不同的虚拟机上，EJB使调试变得很困难（在IDEA里面调试EJB还挺方便）
·EJB过于依赖容器的服务（更换应用服务器时，迁移的工作量很大）
·EJB部署起来很复杂，很慢（实际上我现在已经习惯了）
·使用EJB远程接口牵制了对象设计
·使用EJB会减小应用服务器的可选择范围

本书的部分章节：http://www.wrox.com/books/sample-chapters/samplechapter_0764543857.pdf

2.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: menzy Posted on: 2003-07-16 19:42 stateless session bean 还是应当多用的

3.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: floater Posted on: 2003-07-16 22:04 One more: EJB deployment is more or less server dependent. The only real reason I've found to use EJB is because my boss asked me to do so, otherwise, "hell no", hehe... Could someone give me a valid reason so that you have to use EJB rather than ordinary javabean or general classes(not container dependent)?

4.Re:[讨论]到底用不用EJB？ [Re: floater]	Copy to clipboard
Posted by: muziq Posted on: 2003-07-17 08:13 floater wrote: Could someone give me a valid reason so that you have to use EJB rather than ordinary javabean or general classes(not container dependent)? 现在我能想到的唯一的原因就是EJB允许你远程调用

5.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jameszhang Posted on: 2003-07-17 08:34 EJB还是应用于分布式计算上，就是在大量的访问、计算时候有用，把访问与计算分在多台机器上，但不是所有项目都适合应用，WEBLOGIC把EJB搞的有点象WEB应用了，看看SUN APP SERVER 非常注重集群的作用考虑LOAD BALANCE 和 FAILOVER比较多些。（个人观点）呵呵！

6.Re:[讨论]到底用不用EJB？ [Re: jameszhang]

Copy to clipboard

Posted by: muziq
Posted on: 2003-07-17 09:10

jameszhang wrote:
EJB还是应用于分布式计算上，就是在大量的访问、计算时候有用，把访问与计算分在多台机器上，但不是所有项目都适合应用

同意！更准确一点，应当说对大多数项目并不适用。

jameszhang wrote:
WEBLOGIC把EJB搞的有点象WEB应用了

我在BEA培训的时候，BEA自己的人说，WLS就集群做的好，其它方面与别的应用服务器没有太大的差别。现在看来，如果扔掉EJB的话，集群的性能基本上就是应用服务器最重要的特性了吧！

7.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jameszhang Posted on: 2003-07-17 10:01 我不是说WEBLOGIC 的集群不好！我是说我所看到的资料中，BEA所强调的介绍其他方面比重大，所以给人的一种印象，如果他的集群做的不好，我相信世界500强的那么多企业不会选择他做APP SERVER了，呵呵！（又挨骂了）

8.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: muziq Posted on: 2003-07-17 11:02 我没骂你啊！（你太敏感了，是不是经常被骂啊？）

9.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jinf11 Posted on: 2003-07-17 16:35 通过我自己的工作经验，我感觉EJB还是很有用处的，我现在做的证券集中交易系统就非常适合用ejb。

10.Re:[讨论]到底用不用EJB？ [Re: jinf11]	Copy to clipboard
Posted by: muziq Posted on: 2003-07-17 17:00 能不能针对大家的讨论内容谈的再具体些？

11.Re:[讨论]到底用不用EJB？ [Re: muziq]

Copy to clipboard

Posted by: speeddemon
Posted on: 2003-07-21 17:51

我使用EJB的理由在于：
1、组件化。
这样一个精心设计的业务组件可以被高度重用。
2、容器负责事务、对象的创建与销毁。
在需要事务的应用中非常有优势。
3、分布。
分布的好处就不说了。
4、开发代价小。
开发简单。

不过在做决定时同样有很多缺陷也值得我们权衡：
1、性能
这个就不说了...
2、测试部署麻烦
在环境不具备前，工程量甚大；如果team中有专门的角色作这类工作，这一点影响就可以忽略了
3、滥用
为了EJB而EJB的情况太多了，大家都忘了，真正的判断标准应该是为了满足需求而EJB

12.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jameszhang Posted on: 2003-07-22 07:58 muziq wrote: 我没骂你啊！（你太敏感了，是不是经常被骂啊？）我在开玩笑！呵呵

13.Re:[讨论]到底用不用EJB？ [Re: speeddemon]

Copy to clipboard

Posted by: muziq
Posted on: 2003-07-22 08:36

speeddemon wrote:
我使用EJB的理由在于：
1、组件化。
这样一个精心设计的业务组件可以被高度重用。

没错，但是JDO和Hibernate也是可以组件化的，而且在重用时也比EJB简单。

speeddemon wrote:
2、容器负责事务、对象的创建与销毁。
在需要事务的应用中非常有优势。

容器管理事务也有两面性：简单是简单了，但是程序会变得难读，你必须看ejb-jar.xml才能知道方法的事务属性。

speeddemon wrote:
3、分布。
分布的好处就不说了。

speeddemon还是说说吧！这方面我真的是不太了解，我只觉得分布是为了负载均衡，但是集群不是也可以负载均衡吗？

speeddemon wrote:
4、开发代价小。
开发简单。

这个……这个恐怕很少会有人同意吧？

BTW，昨天我又想起刚开始接触EJB的时候，领悟到EJB可以使组件与数据库实现无关，但是后来为了平衡性能，要JDBC for reading，这样不就又和数据库实现产生依赖了吗？

14.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: muziq Posted on: 2003-07-22 08:43 关于分布：是不是整个应用大到机器的内存硬盘吃不消，必须分装到多台机器上，这个时候就要分布了？如果只是CPU忙不过来，我想集群应该也能胜任负载的均衡。

15.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: salaris Posted on: 2003-07-22 11:07 to jinf11 : 我觉得集中交易系统不应采用EJB,性能有问题. 委托服务实时性要求太高<

16.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jameszhang Posted on: 2003-07-22 11:46 muziq wrote: 关于分布：是不是整个应用大到机器的内存硬盘吃不消，必须分装到多台机器上，这个时候就要分布了？如果只是CPU忙不过来，我想集群应该也能胜任负载的均衡。我认为集群是分布式应用的一种形式（个人意见）

17.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: muziq Posted on: 2003-07-22 14:29 我理解的“分布式”是指将组件分别部署到几台服务器上

18.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: jameszhang Posted on: 2003-07-22 15:50 muziq wrote: 我理解的“分布式”是指将组件分别部署到几台服务器上我理解的“分布式”是将大量计算任务按照某种规则分给多个CPU来完成！

19.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: qilong2000 Posted on: 2003-07-23 10:08 you can use jdo

20.Re:[讨论]到底用不用EJB？ [Re: muziq]

Copy to clipboard

Posted by: speeddemon
Posted on: 2003-07-23 15:48

muziq wrote:
没错，但是JDO和Hibernate也是可以组件化的，而且在重用时也比EJB简单。

容器管理事务也有两面性：简单是简单了，但是程序会变得难读，你必须看ejb-jar.xml才能知道方法的事务属性。

speeddemon还是说说吧！这方面我真的是不太了解，我只觉得分布是为了负载均衡，但是集群不是也可以负载均衡吗？

这个……这个恐怕很少会有人同意吧？

BTW，昨天我又想起刚开始接触EJB的时候，领悟到EJB可以使组件与数据库实现无关，但是后来为了平衡性能，要JDBC for reading，这样不就又和数据库实现产生依赖了吗？

解释一下：
理由之1和4都是因为，我的团队已经熟悉EJB开发技术，并且在开发过程中已经形成一套设计、开发规范，如果转向其他技术，成本很大，而且以前的培训成本、开发经验等等都被浪费。我考虑问题不是只从技术出发，这点原来没有写清楚。

21.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: speeddemon Posted on: 2003-07-23 15:58 另外一点就是关于开发难度的问题我觉得EJB的开发难度并不大，只要开发人员初期概念准确，实作阶段多练习，配合工具，掌握了之后是很容易的。

22.Re:[讨论]到底用不用EJB？ [Re: speeddemon]

Copy to clipboard

Posted by: jameszhang
Posted on: 2003-07-24 14:26

speeddemon wrote:
另外一点就是关于开发难度的问题
我觉得EJB的开发难度并不大，只要开发人员初期概念准确，实作阶段多练习，配合工具，掌握了之后是很容易的。

同意！EJB开发难度并不大，但我认为开发前的设计不容易，考虑的方面很多！如果设计完成，后期开发和维护比其他的开发要简单。

23.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: speeddemon Posted on: 2003-07-24 16:12 关于分布式计算：分布的直接原因是成本而不是出于技术上的需要。由多台处于不同地理位置的较廉价的PC机执行过去由大型机、小型机集中执行的处理任务，不论是一次投资成本还是总体拥有成本都要低一些，而且可以利用很多已有资源...

24.Re:[讨论]到底用不用EJB？ [Re: muziq]	Copy to clipboard
Posted by: zwzapple Posted on: 2003-08-11 18:13 还丢了一点：并发控制。呵呵。有人觉得用jdbc写sql快。我觉得用ejb persistence快。不知道大家有什么意见？对于middle-gen ,xdoclet,velocity等等这些工具，在提高ejb开发效率上提供的巨大的帮助。开发量可以说是爆减少。

25.Re:[讨论]到底用不用EJB？ [Re: muziq]

Copy to clipboard

Posted by: muziq
Posted on: 2003-08-12 08:46

多个EJB组件（JAR）的EntityBean之间不能建立关系；
EntityBean继承很麻烦，不直观，加上上面一条的限制，给重用造成很大障碍，同时也给设计造成干扰（设计偏离了面向对象的思路，而必须考虑容器的存在）；
由于缓冲机制的限制，不能做大数据量的处理，这样就不得不用JDBC或者存储过程来替代，而我们总希望业务逻辑集中在中间层而不出现在数据库层以便于移植；
同时，很多用户交互过程的开始要查询分页的数据供用户选择，而这种查询不可能由EntityBean完成，必须又要交给JDBC

我们需要一个更好的O/R映射的框架，它能够完整的封装业务逻辑、能够实现纯粹的面向对象设计、整个应用不依赖于任何数据库和应用服务器平台，Hibernate就是这样的一个选择。

而SessionBean由于具有RMI以及事务管理的能力仍会有很强的生命力。