某大公司的人说：国内公司很少真正用EJB做东西的，尤其是实体bean。真的这样吗？

既然你没经验，最好是听技术顾问的。EJB最大的问题还不是效率，而是巨大的复杂度。EJB提供了业务层及持久层的一揽子解决方案，能够为J2EE application提供强大的分布式能力。在entity bean这里，这种能力主要体现为分布式事务管理和负载均衡。这是EJB最大的优点，也是它最大的弱点：对于没有分布式需求的application，EJB增加了极大的、而且是毫无价值的复杂度。如果你们的application没有打算做成分布式的，EJB绝对会是一个不必要的负担。实际情况正如这位顾问所说，国内企业很少有用EJB做项目的（做产品的可能会用到），O/R mapping完全可以用Hibernate之类轻量级框架实现，session bean在非分布的application中就更是毫无价值可言，基于POJO的facade加上自定义的事务机制（或者是JTA）就可以取代它。对于非分布的中小型项目，EJB不可能减轻开发负担，同时也不可能提供比基于Java Bean的ORM更好的复用性。不过这位顾问说的性能实验恐怕多少有点问题。几十个entity bean class是不可能把服务器跑死的，哪怕你只是用PC Server。也许他是想吓吓你们，也许是因为他的系统没有tuning到很好的状态。

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

很难想像没有ejb的j2ee是什么东东.不过如果系统不需要考虑扩展性的话的确可以说ejb的效率比jdbc差一点.毕竟ejb在jdbc的基础上又多了一层转换.但对一个大项目(如有5000个终端.200个并发)可扩展性就不得不考虑了.如果业务扩展,架构如何扩展.在这种情况下,牺牲一点性能换来如此巨大的扩展是非常划算的.
ps:你们的server也太水了.这样也挂了,还不如我的pc呢
我们所讨论的项目，实际上是权限管理系统，是mis的一部分。后台数据层是db，前台servelet接受用户的request，会有很多并发。有必要用ejb吗？
to AllError(错误大全) ：你说的所谓可扩展性指的是extensibility还是scalability呢？，难道仅仅指能够支持多个并发，多个终端吗？
我一直不明白什么叫分布式
有客户端又有服务器算不算分布式
Schlemiel(维特根斯坦的扇子) 能不能给我们举个分布式的例子
to AllError(错误大全)：持久层机制（或者说，ORM机制）并非只有entity bean一种。而且——即使在现在的Sun眼中——entity bean并不一定是最优秀的一种。正如你所说，使用EJB的确可以带来巨大的可扩展性（因为内建地支持分布），但同时也带来巨大的复杂度。两者之间孰轻孰重，仍然是一个值得衡量的问题，很多时候你永远不会需要那些可扩展性。5000个终端、200个并发的负载，对于AIX小型机和WebSphere应用服务器来说是轻而易举，还不到非分布不可的地步。而且，即便追求可扩展性，也并不是非要第一时间上EJB不可的。在我看来，一个J2EE application在其本身的architecture和design上就必须有足够的可扩展性，而不是依赖于任何特定的技术。就拿持久层来说，究竟用entity bean、用Hibernate/JDO还是用pure JDBC，那都是持久层内部实现机制的问题，不应该对持久层接口以上的部分造成任何影响。甚至于，按照AOP的观点，“使用哪种具体持久机制”只是持久层设计的一个方面（aspect），持久层的设计应该提供足够的灵活性，允许插入、替换不同的持久机制。与你的观点不同，国外更多的J2EE专家认为EJB应该只是J2EE的一个optional feature，而非necessary feature。不使用EJB，同样可以做出优秀的J2EE application。而且，正如我所说的，在你的architecture里，EJB应该只是一种可供选择的实现路线，而不是技术的guideline。当然这对architecture和design的要求就更高了。一些盲目崇拜EJB的architect做出来的application，整个system都是围绕EJB展开的，完全丧失了插入其他实现机制所需的灵活性。在我看来，这样的J2EE application才是典型的anti patterns。
话是不错。国内现在做实体Bean的的确不多。
能将Session Bean、X Bean 做好的更少。
to guogallop(迂回者)：
任何一个J2EE application必然是有client和server的。J2EE的“分布式”是指服务器端的distribution，也就是说在多台服务器（或者干脆就是服务器集群）上运行application。如果你熟悉Java Classloader就会知道，在集群上处理同步、缓存、事务之类的问题会很麻烦，甚至就是一个Singleton就能搞死你。所以EJB的存在是有其价值的。to minxlover(robert)：
我想他说的“可扩展性”是指scalability，而我更强调extensibility——在我看来，如果满足了后者，前者可以相对容易地达到。再强大的服务器、再强大的技术，必定是有其负载极限的。虽然AIX小型机很强，如果并发过大，肯定就非要分布不可了，这时一个extensible的application会比较容易地获得scalability。
我看你应该从用户的角度出发，先度量一下常规的和极限的负载情况，再做决定。
刚刚请教了一比较熟悉这一行地说，他说：ejb的可扩展性指可以比较容易根据软件需求的更改对程序进行修改。我想这应该叫做软件的可维护性好。按照 Schlemiel(维特根斯坦的扇子) 的说法,可扩展性应该是指ejb的容易分布在多个服务器上？请指教
呵呵，那是另外一回事了。我们的用词存在着严重的混淆，都怪技术发展太快，让我们的语言来不及跟上变化。“比较容易根据软件需求的更改对程序进行修改”，我觉得这是每个面向对象软件必然拥有的特性——换句话说，如果没有这个特性，你的程序就不配叫“面向对象”。在做OOA/OOD的时候，这方面的灵活性就是题中应有之义，不管用不用EJB（或者别的什么技术）。EJB的distribution能力几乎是天生的，部署到多个服务器不是“容易”，而是“理所当然”。
那么Schlemiel(维特根斯坦的扇子)你所说的ejb的可扩展性就应该是她对分布的天生支持能力？照这样说，ejb天生就具有好的可扩展性？
可以这样说。如果scalability对于你的application很重要的话，把EJB作为first-class concept应该是合理的。
呵呵.我只是随便举了个例子,就拿这个例子说说ejb的扩展性吧.如果当初我的server是为5000个终端200个并发考虑的,但业务在一段时间后也扩展了.可能到了10000个终端.400个并发了.如果架构设计不好,可能前期的投资就白费了.或又要浪费大量的金钱修改.如果用了ejb的话.就可以把一些entitybean部署到别的server上.使之负载均衡.使升级费用减至最少.
to： Schlemiel(维特根斯坦的扇子)
j2ee的确有很多内容.只不过我个人很喜欢ejb.多谢提点.
to AllError(错误大全)：
你是对的。当scalability非常重要时，值得投入更大的复杂度去采用EJB。设计就是一个不断权衡的过程，扩展性和简单性之间的权衡只是一个方面。
其实在选择技术时，技术角度的考虑和心理角度的考虑同样存在着权衡。就像你所说的，你很喜欢EJB——如果作为技术的选择者，我会希望手下的开发者都没有这样的偏爱，仅仅从技术本身的适用性来考虑问题。但显然这是不可能的，如果他们谁都不偏爱哪一项技术，可以想象他们的技术水平（和热情）也不会很高。所以这也是个相当重要的权衡：选择最合适当前环境的技术，还是选择团队最愿意用的技术？尤其当你已经拥有一支“胶凝团队”，不太愿意换血的时候。
to  Schlemiel(维特根斯坦的扇子) :
有些情况的确如你所说.呵呵,这么晚了大家还在研究技术.注意身体啊...
学习
从个人角度来说，我喜欢用EJB，JDBC太简单了
http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf是一个关于ejb 应用程序的效率和扩展的测试的说明。硬件
PIII 933MHz
CPU with 1GB SDRAM, and two Quantum Atlas 9GB
10,000rpm Ultra160 SCSI disk drives. A number of PII 450MHz
machines run the client emulation software. We use enough client
emulation machines to make sure that the clients do not become a
bottleneck in any of our experiments. All machines are connected
through a switched 100Mbps Ethernet LAN.
app server用1
1jboss2.4（还有3.0）Dynamic proxy based container
2jonas2.5 Pre-compiled approach测试用的example是一个拍卖网站。
用了6不同种设计风格的实现。代码的规模如下
0 纯servlet实现（数据库操作在servlet中完成）。 25个class和4590行代码
1 servlet＋session bean（session bean封装数据库操作，只用到app的pooling和事物服务）。76个class和8000行代码
2DAO separation with Entity Beans CMP 。63个class和10760行代码
3DAO separation with Entity Beans BMP。 25个class和4590行代码
4EJB 2.0 local interfaces。 113个class和13795行代码
5Session facade。  107个class和13440行代码
测试结果：
0的速度最快，1的速度和0接近。。可以在1200个用户连接下每分钟执行一万次的响应，纯servlet实现可以达到12000次。
（interactions per minute ）
一旦用到bmp或cmp，速度就慢了。最好的EJB 2.0 local方式只能在460个用户连接下每分钟执行不到4500次的响应
而bmp只能在220个用户连接下每分钟执行不到2000次的响应，用户再多，interactions per minute也高不了（还会下降）。呵呵，没什么好说的了，使用entity bean，代码量大，速度也够慢，好郁闷。。
2002年测试的东西，不知道现在怎么样了。。微软叫嚣.net的pet sore有ejb实现的10倍速度是有可能的
要追求速度，除了servlet，就只用无状态session bean，
这和com+组件的设计原则（使用无状态对象和存储过程）是一样的。
java的stateless session beans的效率比com+的无状态对象的效率要高一些。
大部分java app server是 1个stateless session beans服务所有的client。
com+是1个无状态对象服务一个client。
微软的.NET petstore刚发布出来没几天就被Oberg发现用了大量的SQL Server存储过程提升效率，简直就是一个笑话。
对于ENTITY BEAN的速度，我觉得太慢了，我做过一个EJB的项目，在一个JSP页面上用到了3个实体BEAN来显示不同数据，数据量都只有10多条，可打开这个页面就象用56K的猫拨号上网一样，太慢了，
JSP为什么会知道entity bean的存在？presentation层的技术，为什么会知道persistence层的实现细节？
大多数时候，当你抱怨一种技术时，请先看看自己是不是非常愚蠢地误用了它。
ENTITY BEAN的速度，我觉得太慢了，我做过一个EJB的项目，在一个JSP页面上用到了3个实体BEAN来显示不同数据，数据量都只有10多条，可打开这个页面就象用56K的猫拨号上网一样，太慢了，
对一个Jsp用那个EntityBean，我想这本身的设计就有问题，不是我们有了EntityBean,为一个实体都要写一个Bean来
其实Ejb只是J2ee中一个部分而已，现在应用很多成功的产品都没有用到EJB,第一个EJB速度本身是一个问题!EJB的移值本身也存在很多的问题(我是说的从一种Application Server移到另一个Application Server中去)，因为每一种Application为Ejb的实现都加入和Application Server本身相关的东西.对于项目来说，无所谓而对于产品来说，那可能是一个很重要的因素了。
关注。真牛！小弟刚刚学java.问一下大哥。是不是java项目最后发布都要用java ***启动呢？不能做成*.exe之类的启动文件吗？感谢回答。
"而据微软宣称，Visual Studio.Net能支持25种语言，和Java相比具有节省2/3程序代码、效能快28倍，承载六倍的使用者的功能"（用.net开发pet store）
微软当然是自卖自夸，误导听众。。如果
http://www.cs.rice.edu/CS/Systems/DynaServer/perf_scalability_ejb.pdf
是可信的话，
那么应该是：
在j2ee的各种设计风格中：
servlet（还有statless session bean）比ejb“节省2/3程序代码、承载六倍的使用者的功能，效能快？倍（六倍的使用者和6倍的响应速度，怎么算啊？36倍吗？）”
ibm人自己说的，他们用实体bean也比较少，ejb用的最多的就是session bean
的确是好贴，很久没在Java版看到如此精彩的帖子了。
本人前段时间“有幸”参与了一个比较大的J2EE日本外包项目，
采用日本某知名大企业自行开发的一套MVC框架，
JSP+Servlet+SessionBean(CMP), Server使用的是WEB Logic，数据库为Oracle 9i.
该项目是为一个日本的县级政府机关管理其公共事业使用的，如县内公共事业工程的竞标管理，
预算管理，工程的实际进度管理（我接触到的部分），整个项目的确非常庞大，是我接触过的最大的项目。
由于项目的显示层采用了JSP代码与HTML代码分离的技术，即在JSP中将HTML模板文件读入，然后进行特定标志的替换，如果数据查询的结果行数非常多，那么在生成页面时就会产生大量的文件IO操作因为显示在页面上的每一条纪录都是一个HTML模板，而搞笑的是只要有一条纪录就要将模板文件读入一次，进行一次IO操作，困惑。可能是机器配置不行吧，实际编码调试过程中总是非常慢，很担心实际的使用效果。然而经“高人”指点，我等的顾虑实在是多余，因为整个系统虽然大，但是真正的用户也就是办公室里的几个人而已。当询问既然如此，有必要使用EJB时，得到的答复根本不是技术性的，而是：
这样日本人可以从日本人那里赚到更多得Money！！！！！
从技术的角度来讲，我们考虑的是开发的高效项目以后的可扩展性等，
但是从经营的角度来讲，可能考虑的是更多的利润，
其实有很多项目最终采取的开发方式并非是技术上最高效的，
至少日本人的很多项目就是如此，他们特别喜欢赶新潮，
我想这一点也不能忽视！
所以话又说回来，到底是技术决定业务还是反过来呢？还是本来就是相辅相成的呢？
不错用了j2ee，尤其是EJB来说可以圈得很多的钱，但有多少是自己的呢？
以前我们做产品和项目时都要用EntityBean，效率不高是无可厚非的，现在我们主SessionBean加自己的数据处理层
不错的帖子，原来这里也不仅仅是helloworld和classpath的地方
我在的公司，为了性能甚至可以牺牲OO，简直把java当C来写
看你们如何考虑了，采用了好的架构对系统维护更新等有好处
也许同时降低了性能，其中谁好谁坏要看实际用途
如果系统要每天支撑几百万访问，性能是首先要考虑的
如果每天就几个人办公使用，多些考虑设计，采用先进架构
小项目有必要用ejb吗？
大项目若是用ejb他们的服务器会差吗？
损失点速度换来扩展性，还是值得的！
个人而言，我极其反对“为了性能牺牲OO”的做法。系统90%的性能瓶颈一般会集中在10%的代码（例如事务操作、RPC），如果没有良好的OO设计，第一你很难把瓶颈隔离出来，第二你很难用更好的算法去替代现有的算法。
好的架构和设计与好的性能并不矛盾，很多时候前者是后者的先决条件，因为良好的设计使你更容易profiling和tuning。另一方面，架构和设计是否良好，并不取决于是否采用某种技术，那基本上纯粹是一个OO的问题。优秀的J2EE应用首先必须是优秀的Java应用，具体的技术应该是第二位考虑的。
to ： etre(林荃)
ejb速度慢只是相对jdbc来说的.并不会慢的象你所说的那么慢.在我测试server上ejb查找,插入记录只需要0.0几秒的时间.