我知道如果我再问ejb意义何在，肯定有人会丢我鸡蛋，但是我真的很不明白

EJB垃圾，但是工资高.............
我认为，5000万块以下的项目不要用EJB

解决方案 »

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

实体EJB 是用来进行数据持久化的一种方案
EJB容器提供的事务、安全、分布式应用等特性，如果用普通的程序实现很难啊EJB组件的思想
j2ee跟.net都学过一些，感觉.net确实比j2ee好用些，com+并不像想象中的复杂，到是J2EE平台，慢不说，有时还会出些莫名其妙的问题，可能是我很菜吧，顺便问一下，J2EE1.3里用DEPLOYTOOL怎么注册别的服务器？客户端是不是只要有DEPLOY出来的JAR就可以运行？客户端可以正常运行的必要条件（编程及服务器配置方面）是什么？
下面几个问题帮助你最好理解为什么要用EJB
1，分布式问题：如果你有几台服务器，跑的都是同一套系统，分别在北京，上海，广州，如果北京有个用户改了他的资料，那么要发通知上海和广州的机器也做同样的事，否则他跑到广州一看，怎么改了的还是没有变呀。这就涉及到一个普遍的分布式处理问题了，如果你自己写网络通信实现，写一大堆SOCKET，复杂的要死，还出错。你这时多么希望有个中间件能帮你解决这些问题呀，没错，想到EJB！
2，事务问题：如果你在做了一个内部人员管理系统，现在有一个人首先到人事部登记，登记完有去财务部登记，忽然这个时候，系统掉电了。结果这个人在人事部有记录，但是他没有工资，因为他没有成功录入进财务部数据库。这个时候就要面临一个事务问题了，希望它要么一次都成功，要么一次都不成功。怎么做呢，如果你自己用其他办法实现，写一大堆代码，复杂的要死，还出错。你这时多么希望有个中间件能帮你解决这些问题呀，没错，想到EJB！
其他还有多线程，安全等等问题。
等你发现用了EJB，头不痛了，心不烦了，程序变简单了，可以专注于系统的业务实现了，那你就会说：我呀，一直用EJB，EJB呀，天天见！
"我呀，一直用EJB，EJB呀，天天见"
楼上的强，呵呵
其实这个问题并不像看起来那么低级。应该说，这是个相当有意思的问题。EJB这种重量级的方案，真的有（Sun所鼓吹的）那么重要吗？tianboguang(其实，我是一个程序员)做了精彩的介绍，可惜，全都没说到点子上。（1）这个所谓的“分布式问题”应该是由数据库来解决的，几个地方的系统应该连接统一的中央数据库，或者提供数据库同步机制（可能是通过触发器）。（2）事务问题，这是持久化方案必须考虑的问题，但任何一个non-trivial的O/R映射框架都会提供事务支持，这并不是实体bean的优势所在。作为一种持久化方案，实体bean其实就是非常糟糕：沉重、缓慢、复杂。传说中实体bean可以提供分布式能力，但自从EJB 2.0以后，Sun一直推荐用实体bean实现本地接口，分布式的能力实际上是由session bean来提供的。现在J2EE社群普遍认为，基于POJO（Plain-Old Java Object）和AOP（可能只是动态代理）的轻量级持久化方案是更好的选择，JDO和Hibernate是这类方案的代表。今天早上看到TSS的新闻，Hibernate已经加入了JBoss阵营。JBoss CMP曾经是CMP实体bean的代表，但现在JBoss要用Hibernate取代CMP作为持久化基础设施了，技术发展的方向由此可见一斑。在我看来，EJB唯一的价值就在于session bean提供的facade。如果你的应用需要多服务器集群，通常会需要session bean；如果你的应用需要面向多种client（而不仅仅是web client）提供服务，也许session bean是一个不错的选择。如果没有这样的情况，那么EJB实际上毫无意义，只会增加巨大的复杂度。用Rod Johnson的话来说，“EJB应该只是J2EE的一种可选特性，而非核心特性。”
呵呵，既然你已经认定EJB是J2EE最核心的技术，那还有什么好说的呢？不用着急上火，你喜欢用EJB就继续用好了，没有什么不好的。
to  tianboguang(其实，我是一个程序员) :
数据库也可以用分布式数据库，你说的EJB的分布式和这是不一样的，ejb的分布式是架构在RMI之上的组件模型，和数据库没有什么关系
另外，实体bean 就是一种O/R maping方案如果你是OO的数据库，那在O/R maping 这里就不需要用实体bean 了
其实对于O/R maping方案(PO方案)，来说，实体bean 不是好的选择，与其选择它还不如选择轻量级的JDO,Hibernate等，这其中的Hibernate是目前最好的选择
tianboguang(其实，我是一个程序员) 说的好啊
继续学习
to  tianboguang(其实，我是一个程序员) :
数据库也可以用分布式数据库，你说的EJB的分布式和这是不一样的，ejb的分布式是架构在RMI之上的组件模型，和数据库没有什么关系
另外，实体bean 就是一种O/R maping方案如果你是OO的数据库，那在O/R maping 这里就不需要用实体bean 了
其实对于O/R maping方案(PO方案)，来说，实体bean 不是好的选择，与其选择它还不如选择轻量级的JDO,Hibernate等，这其中的Hibernate是目前最好的选择
EJB还是很有用的，只是多数情况下你不知怎么用它。
有些人只会喊这不好，那不好。这个是垃圾，那个是垃圾，到最后连自己也会变垃圾的
   EJB:

      JAVA"多层"开发中的重要一环,在应用级层次上操作数据
偶在ejb上涉及不多，感觉session bean确实是很好的设计，entity bean感觉太复杂，缺少效率
偶在ejb上涉及不多，感觉session bean确实是很好的设计，entity bean感觉太复杂，缺少效率
建议各位看看这条新闻，以及TSS一贯的热烈讨论：http://www.theserverside.com/home/thread.jsp?thread_id=21482记性好一些的同志可能会记得Marc Fleury那篇热情洋溢的“Why I Love EJB”。时至今日，来自JBOSS首席体系结构师Bill Burke的声音却是“use Hibernate to replace the clunky design that EJB CMP is”。EJB CMP的“clunky design”，来自业界CMP技术最先进的JBOSS，多么有趣的评价。
Schlemiel(维特根斯坦的扇子) ：
这样吧，如果你已经熟练掌握了Hibernate，你用写它一个例子贴在这里，描述它是怎样封装对象数据库的，然后详细说明它比EJB要更有优势的地方，这样最具有说服力，如果我们都从你的例子里感受到Hibernate确实比EJB更强大而且简单好用，那我们就去否定EJB，而改用Hibernate怎么样，这也是本着追求真理的精神，对待一项新出现技术的正确态度。
从这个帖子我忽然想到很多题外话，我在现实生活中面临的，曾经我的小组里也个别组员，他总喜欢提出不同的意见，总喜欢用市场上的某项新技术来否定我们一致的决策，当项目里用JSP的时候，他说要用XML；当选用JDK1.4,他说现在1.5都出来了；当统一装WINDOWS2000，他偏要装WINDOWSXP；我曾经为怎么和这样的人配合好而大伤脑筋，因为他提的那些建议并不是真的从我们这个项目，这个团队出发，多半这样的组员都才毕业，几乎没有什么项目的经验，他对那些最新的技术又能了解多少呢，他这样做其实是出于一种想表现自己的能力，让别人知道他了解很多新技术。如果你强行否定他呢，对大家的关系和队伍的团结都是大的破坏。呵呵，罗嗦的太多了。
to tianboguang(其实，我是一个程序员)：Are you joking？拿一个例子贴在……这里？一个不好笑的玩笑。你误用了“真理”这个词。选择什么技术，很大程度上只是一个工程学问题，顶多再加上些个人的口味偏好，跟真理没有任何关系。难道你没有看清，我在前面一次回复里说“多么有趣的评价”吗？是的，看见曾经最热诚的CMP拥趸改变自己的口味，于我是一个饶有兴味的现象，但也仅此而已，与真理无涉。同样，如果你愿意认为我是无知的新技术盲从者，也悉听尊便。毕竟我并不在乎你对我的看法，正如我并不关心你是否愿意继续用EJB一样。在我看来，J2EE的世界可以用一句老话来形容：“There's nothing new under the SUN”。不过我没必要为自己证明什么，毕竟你又不是我的leader。
其实，我也一样，我不知道ejb究竟有什么好处。
一开始的时候，公司让我用ejb，后来，时间不够了，
改了，让我用javabean了----这里的javabean是一种以我们自己的格式封装过了的javabean。类似于ejb，但是，却省掉abstract类,home口等。
当时我不明白为什么，我甚至不知道，session bean ,entity bean,普通的bean，他们有什么区别。
后来我去问了技术主监，他告诉我，不要把他们想的太复杂了，ejb，不过也就是一些有一定规范bean。利用这些规范，在做分布式的时候，部署起来比较容易。而且，他还告诉我，说这个领域还有一种职业，那就是部署师。
到现在，我还是没有明白ejb的好处......因为我们现在做的项目根本就不用考虑部署的问题。
悲剧啊。偶不知道我们技术主监说的对不对，但是，
偶应该开始好好学习了......:(
另外，你举了一个糟糕的例子……基于XSLT的view技术历史并不短，至少不会比JSP更短（JSP 1.0规范是1999年发布的）。你可以看看这篇帖子的源码，这就是一个在ASP+IIS平台上使用XSLT view的范例。不知道什么时候，XSLT view竟然也成了“市场上的新技术”？J2SE 1.5到现在为止仍然只有“Tiger”这样一个代号和两个Early Access的预编译器，离“出来”还早得很呢。在O/R mapping这里，情况也一样。直到2001年8月发布的EJB 2.0加上了local interface，entity bean才真正成为一个实用的工业级O/R mapping解决方案。而在Sun的一体化解决方案（EJB）之前很多年，甚至早在Java诞生之前，基于普通对象的轻量级O/R mapping方案就已经相当成熟（同时也相当清楚地遇到了对象模型与关系数据库的阻抗不匹配）。基于这样一个老概念的hibernate竟然也成了“市场上的新技术”，再一次莫名。实在没必要强调你比我多的那一点实践经验（真的多那么一点么？这还是个问题）。在真正的高手面前，我们的经验都约等于0。很多时候，重蹈覆辙并不是一件很聪明的事。想知道J2EE主流社群对CMP的观点么？Rod Johnson的Expert One-to-One J2EE Design and Development或许可以给你一些帮助。Rickard Oberg？实在不愿意让你看到他对EJB的评论——好象他早已不再评论EJB了。
转载两则重大消息1          Hibernate和JBoss Group合作Hibernate的作者Gavin King目前被JBoss Group雇佣，被受命全职开发Hibernate以及Hibernate和JBoss的整合工作。JBoss将使用Hibernate作为CMP的内核引擎。这次的合作可以说是JBoss和Hibernate的双赢，JBoss得到了一个优秀的持久层引擎，而Hibernate背靠JBoss Group的资源，可以得到更好更快的发展！！！现在那些对Hibernate怀着刻骨偏见的人可以重新审视一下自己的观点了。详细情况请看这里： http://forum.hibernate.org/viewtopic.php?p=2268&highlight=#2268 另外整个Hibernate Team正在忙忙碌碌的准备下周一举办的JAOO，Hibernate Team将进行产品的展示，这将大大有利于扩大Hibernate的影响力。
2      爆炸性消息：Hibernate将兼容JDO2.0！！！！！
在Hibernate官方论坛看到的消息，Hibernate Team核心开发成员Max说：如果JDO2.0标准足够好的话，那么Hibernate将兼容JDO2.0，并且Gavin King已经是JDO标准的专家组成员，主要负责制订JDO2.0标准。
--------------------------------------------------------------------------
谁还敢说Hibernate没有前途，Hibernate不是标准？
--------------------------------------------------------------------------
转贴
                我来谈谈我为什么学习Hibernate，希望对大家能有点启发。
作者   robbin   (http://hibernate.fankai.com/ 站长)我来谈谈我为什么学习Hibernate，希望对大家能有点启发。在我做过的很多项目的过程中，我一直有一个悬而未决的问题在困扰我，那就是持久层的开发。持久层的开发一般来说要么用CMP，要么用JDBC＋DAO。 CMP就不用说了，它对我来说是一种失败的实践，而JDBC+DAO也存在很多的困难，我很难做到把关系表记录完整的映射到持久对象的关系上来，这主要体现在多表的关系无法直接映射到对持久对象的映射上来，可能是一个表映射多个持久对象，有可能是多个表映射一个持久对象，更有可能的是表的某些字段映射到一个持久对象，但是另外一些字段映射到别的持久对象上。而且即使这些问题都处理好了，也不能直接按照对象的方式来对持久对象（PO）编程，因为存在1：N关系的持久对象的查询其实就是1+n次对数据库的SQL，我曾经有一次失败的持久层设计，结果是某个关联很多其它持久对象的PO一查询就是5n＋1次 sql，速度慢的不得了，最后不得不整个修改底层设计，最后等于是完全抛弃了对象设计，完全是按照表字段进行操作。但是这样做非常难受，因为系统的设计是从需求设计，系统设计这样自顶而下的，结果都到了详细设计阶段了，被持久层映射问题限制，不得不自底向上修改设计方案，又回到了按照过程进行编程的老路上来，非常的糟糕。我对这个问题思考了很久，最后终于意识到这其实是一个很经典的问题：对象和关系的映射问题。实际上自从OOP编程流行以后，就存在这个难题了，所以才有人提出关系数据库进行重新设计，改用对象数据库，但实际上关系数据库并没有被淘汰，于是就只能在上层的应用层找解决方案。这时候我明白了我需要的实际上是一种 ORM产品。我最早想到的ORM就是JDO，于是我下载了两个JDO产品，准备认真的学习一下，但是研究了一段时间之后，我发现我对JDO非常的失望，原因如下： 1、 JDO没有一个好的开源免费实现，好的产品都是商业产品，并且在国内没有销售和技术支持。这就造成了JDO只有学习之用，不能把它用在实际项目中，否则的话，你把软件卖给客户的时候，还要告诉他，你还要另外去买一个国外的软件产品，并且在国内没有技术支持，出了持久层的问题，我们也解决不了，请你自己打国际长途去解决问题，你认为客户能答应吗？ 2、JDO不是一个轻量级封装，它试图建立一个完整的持久层框架，但是还很不完善，造成了JDO 感觉比较笨重，很多操作方式令人觉得烦琐和古怪。这加重了程序员学习和编程的负担，而且封装的太多会造成一个严重的问题就是一旦出现报错信息，调试起来非常困难，你很难准确的定位错误究竟出在哪里，封装的越轻，问题越容易定位，越容易解决，封装的越重，问题越复杂，越找不到原因，CMP就是一个很好的例子，出了错误，调试起来非常困难和麻烦。 3、JDO的标准很不完善，存在重大缺陷。最主要的问题体现在PO不能脱离PM（相当于 Hibernate的Session）而存在，这是个非常严重的问题，会造成编程的时候进行大量VO的拷贝操作，烦琐极了；另外一个重大缺陷是静态的 POJO的Enhancer，不能运行期动态Enhance，无法进行增量编译和调试，编程和调试起来非常烦琐，每次都要手共运行一个工具对POJO进行 Enhance；此外还有一些缺陷，例如JDOQL不完善，映射关系的表达不够强大等等。 4、JDO产品的分裂。这个问题也比较严重，由于JDO1.0标准的缺陷，而JDO2.0标准还遥遥无期，而各个JDO厂商为了能够在竞争中脱颖而出，那么除了在易操作性和性能上的提高之外，想要吸引客户，就必须有自己的产品特色。那么1.0标准的缺陷正好给了他们发挥的舞台，每个厂商都会有自己独到的解决方案来解决标准的缺陷，然而这却造成了JDO 产品事实上的分裂。这种分裂严重到什么程度？我可以简单举个例子：你写好的POJO，用一种JDO的Enhancer进行Enhance过以后得到的 PO，在另一个JDO产品上跑不起来。这很像当年Unix的分裂，结果就是二进制代码级的不兼容，而只能在C源代码级兼容。现在的JDO也有这样的趋势，就像App Server的差别一样，一个在Weblogic上开发好的EJB，移植到Websphere，你一定需要重新进行配置。我心目中的ORM最好有如下的特点： 1、开源和免费的License，我可以在需要的时候研究源代码，改写源代码，进行功能的定制。 2、轻量级封装，避免引入过多复杂的问题，调试容易，也减轻程序员的负担。 3、具有可扩展性，API开放，当本身功能不够用的时候，可以自己遍码进行扩展。 4、开发者活跃，产品有稳定的发展保障。抛弃了JDO以后，我根据上面的原则，先后排除了TopLink，CocoBase，Castor等，最后选择了Apache OJB和Hibernate。 OJB的排除很容易做出，一是因为它的文档太简单，太少；二是因为OJB计划下一个版本全面支持JDO，它的API会有重大变动，所以现阶段学习OJB是个错误，等它的API稳定了以后再学习不迟。 Hibernate的发现是很偶然的事情，只是在别人提到JDO的产品中，附带提了提而已，但当我开始研究Hibernate之后，我发现终于找到了我梦寐以求的ORM了。 Hibernate 完全符合我上面提到的标准之外，也解决掉了JDO的所有缺陷，而且方式之优雅令人赞叹。Hibernate的文档也是非常非常有特色的地方，它不仅仅是 Hibernate的功能介绍那么简单，它实际上是一个持久层设计的最佳实践的经验总结，文档里面的例子，文档里面的总结全部都是最佳设计的结晶。我认真的把Hibernate读下来的感觉就是，不单单把Hibernate掌握住了，而且对持久层的设计的经验都长了一大块，以前可从来没有觉得持久层的设计还有那么多的学问，也由此感觉到Gavin绝对是一个大牛人。当然选择Hibernate最最重用的原因是Hibernate是一个我能够完完全全驾驭的了的软件。Hibernate的源代码非常少，而且写的非常简洁，我总觉得挺奇怪的，这么少的源代码能够实现这么多的功能，是个奇迹。 Hibernate的源代码树分的很清楚简单，源代码很易读，我一旦碰到文档中没有讲到的问题，或者文档中提到但是我搞不清楚的地方，我就去源代码中找，所有的问题都豁然开朗，而且让我对Hibernate的运行原理和细节搞的特别清楚，好像Hibernate就像自己写的代码一样，很清楚的知道，怎么写程序可以让Hibernate运行效率最高，最省内存，程序出了错误，很清楚的知道是什么地方的问题，怎么解决。所以用Hibernate让我特别放心，我能够驾驭它，而不像那些过于复杂的软件，本身框架就复杂的很，再加上不开源，出了问题也不知道怎么回事。
to baitianhai(hong)：前天早上在TSS看到这条新闻，激动得差点把茶杯打翻。到今天，那个帖子下面的回复已经有117个了——来自JBOSS的新闻总是能引发最热烈的讨论。至于第二条新闻，说句老实话，早在预料之中。前一阵，JDO 2.0的一些消息放出来的时候，我就已经感觉它的API和Hibernate非常相似，这肯定和Gavin King的加盟不无关系。实际上，JDO和Hibernate可以说是大同小异，尤其在API层面上非常相似，所以Hibernate兼容JDO 2.0也是顺理成章的。说实话，在ORM里使用Enhancer之类的预处理机制是最让人感到莫名烦躁的——正是这个原因，即使要用CMP，我也一定会用JBOSS CMP，基于动态代理的实现可以帮开发者省很多事。不过，到目前为止，Hibernate也并没有robbin说的那么……优美。由于与生俱来的O/R阻抗不匹配（当然还有数据库厂商之间的明争暗斗），我用Hibernate也遇到不少的麻烦。不过robbin的选择标准是很有道理的，现在的Hibernate既开放、又活跃，看起来前途光明。
不懂ejb, 也没用过hibernate,只对ojb有点失败的经验。最终还是回到自己写persistence的老路上。
希望有机会可以感受一下hibernate。对了，我有个一直想不通的问题。
对待分布式事务，首先要求组成事务的各个操作都是可以undo的吧?假如我有一个legacy system（就说idms吧）, 它没有提供undo功能，那么，如果我的一个事务由对关系数据库的储存，对idms数据的更改，对另外一个rmi接口的调用，一个jms的消息的发出等步骤组成，一个事务服务器怎么保证事务的原子性呢?
Schlemiel(维特根斯坦的扇子)， baitianhai(hong) ( ) ， tianboguang(其实，我是一个程序员) ( )
望各位有以教我！谢了！
baitianhai, 难得遇到真正懂hibernate实现的高手，能不能请教一下？
不知道hibernate怎么处理多jvm, 多应用服务器cluster时候的数据同步? 要提高效率，它总要缓存数据吧？那么这个数据更改了的通知怎么做呢？
欧的观点是这样的：
衡量一个东西的好坏，应该考虑的方面很多，通常有这么几个方面：功能，性能，费用！功能里面包含的有很多，扩张性，容错性，兼容性等等性能方面：速度，并发访问速度，连续运行速度等等费用方面：开发费用，维护费用，升级费用等等！综合这些因素，我认为j2ee的优势大大的有！！
SeesionBean 和EntityBean的优势，一直是一个争论的的话题。
to ajoo(聪明的一猪)：Hibernate的缓存是在session对象里的，所以只要保证整个appliaction访问同一个global session，缓存同步的问题自然就不存在了。这是不是你想要的答案？还从来没有遇到过像你第一个问题所说的情况。一般来说，不要说这么复杂的遗留系统，哪怕只是继承历史数据库而不允许新建数据库，我就会放弃ORM，回到JDBC persistence。就我个人的感觉，ORM适用的范畴还是相当相当窄，而且在遗留系统上会遇到巨大的困难。
to Schlemiel(维特根斯坦的扇子) :听到这个消息我也很高兴：）to ajoo(聪明的一猪) :很抱歉，我水平低，所以无法回答
不过关于这个问题，robbin (http://hibernate.fankai.com/的站长）和(http://www.jdon.com/的站长) 曾经说过，应该是可以的
你可以去http://hibernate.fankai.com/向 robbin 本人请教，robbin非常热情的，相信他会给你一个满意的答案的  ：）
补充  (http://www.jdon.com/的站长) 是 bang，刚才没有打上去，不好意思