请高手谈谈用Entity Bean 的体会，到底Entity Bean 有什么优势？我觉得它并没有什么优势啊！

用Entity Bean取出数据，然后可以在一次完整的商务逻辑中对这些数据进行增，删，改，查的工作，全部操作完毕后再提交更新数据库这样，在数据量大，或者网络条件不是很好的时候，就可以大大提高性能

EntityBean的最大优势是他提供给我们一个面向对象的数据模型，并提供容器管理的持久性，事务及方便的数据库连接（避免大量编写数据库连接代码的工作）。避免了对业务逻辑之外的过分关心。
而SessionBean虽然可以也可实现象EB的功能，但是，一个有状态的bean，你能保证他的数据操作的安全性吗？一个无状态的bean,是不能保存会话状态的，你希望在两个方法调用中写两次连接代码吗？但是，要是只做一些读取操作时，无状态BEAN可大大提高性能！

劝你不要多用entity bean ，那个东西对于简单的模型很好用，但是对于巨大的系统来说，你要映射每个表和实体bean的字段关系，移植也非常麻烦。最好还是自己编一些访问数据库的方法（在session bean中）。

chenyuan_tongji(codeguru) 说得好。entity bean的优势在于对付大的应用程序，除了数据封装分层这个人尽皆知的道理，它可以用很大程度的避免数据库的频繁连接也是一个好处。提供一种物件的对象存储方式（关系性数据库）而不需要你自己编写麻烦的代码去到关系性数据库里存取。至于映射嘛，我觉得还行，用cmp嘛。

要映射每个表和实体bean的字段关系(cmp),我们做现在的中国电信新97,用一种叫toplink的东东(这个公司刚被oracle收购了,现在集成在oracle9i中),真是不错哦,可以自动生成映射每个表和实体bean的字段关系的java代码,并有一套管理机制,非常好用,不过现在中文资料基本没有,希望大家闲下来可以看看.

实体Bean：用于映射基础数据库表格，生成数据库的对象视图。例如，如果数据库中有表格Customer，则可以生成一个实体Bean ，将表中每一行映射到Bean,表中每一列映射到Bean的相应实例变量。这样，实体Bean总是状态Bean。实体Bean可以供许多客户机使用，但通常把实体Bean从客户端隐藏起来，只让会话Bean与实体Bean交互
(1)为什么要用Entity Bean?
关系数据库是不是面向对象的东西，EntityBean的本质就是要把二维关系对象化。由于EJB本身所具有的跨平台、支持远程调用等特性，使Entity Bean更适合于大型软件的开发。一个小工程，JDBC+Servlt+JSP足够啦

//这些观点我赞成：asdmonster(asd)说的：
entity bean的优势在于对付大的应用程序，除了数据封装分层这个人尽皆知的道理，它可以用很大程度的避免数据库的频繁连接也是一个好处。提供一种物件的对象存储方式（关系性数据库）而不需要你自己编写麻烦的代码去到关系性数据库里存取。至于映射嘛，我觉得还行，用cmp嘛。
buick555(王飞) 说的：
EntityBean的最大优势是他提供给我们一个面向对象的数据模型，并提供容器管理的持久性，事务及方便的数据库连接（避免大量编写数据库连接代码的工作）。避免了对业务逻辑之外的过分关心。
而SessionBean虽然可以也可实现象EB的功能，但是，一个有状态的bean，你能保证他的数据操作的安全性吗？一个无状态的bean,是不能保存会话状态的，你希望在两个方法调用中写两次连接代码吗？但是，要是只做一些读取操作时，无状态BEAN可大大提高性能！/****************************************************
//我不赞成下面这个观点：jery_lee(jery) 说的:
劝你不要多用entity bean ，那个东西对于简单的模型很好用，但是对于巨大的系统来说，你要映射每个表和实体bean的字段关系，移植也非常麻烦。最好还是自己编一些访问数据库的方法（在session bean中）。
*************************************************/

最好不用实体bean做查询。效率很低，官方测试结果是别jdbc效率慢20%。
另外，影射最好是一一对应的，如果需要多表关联，用session bean 在封装一下。至于2次远程调用问题。现在应用服务器已经做了优化。

其实ejb就是针对大系统的，小系统根本就体现不出优越性。所以楼上的说的大系统不要用ejb，是错误的。

大家为什么不把Entity Bean和Session Bean结合起来呢。在开发的初始阶段，可以用Entity Bean来进行数据库的操作。如果Entity Bean不能满足业务要求时，可以新建Session Bean来继承原来的Entity Bean。希望大家多探讨一下这方面的东西！

Entity Bean 也分BMP和CMP,觉得映射麻烦可以用BMP啊，没人用BMP么？

我不是说大系统不要用EJB,ejb最大的好处是将业务逻辑和显示分离开来。也就是所说的三层结构。
我只是认为CMP,容器管理的实体BEAN,对用户太不透明，什么事情都交给应用服务器的容器帮你完成。其实这些无非是一些数据库操作。
本人以前一直认为CMP多好多好，用过以后才知道，那些操作实在是麻烦，而且换了一个应用就没有办法重新进行再利用。
EJB最大的好处也就是组件的思想。
你自己可以做一个SESSION BEAN来完成所有数据库操作。以后无论什么系统你都可以进行再利用，而不需要进行那么繁琐而且不透明的映射和容器管理。
以上只是个人意见，希望多多交流。

我个人觉得嘛，所有的系统，真正通用的地方不是特别多的，如果系统可以靠以往的各种代码来拼凑，我觉得，performance一定问题（台湾人语），真正可能会重用的只是中间的一些逻辑处理不牵涉具体数据的部分。

由于没有真正的在大系统中进行过实践和比较，我暂时同意jery_lee的观点。

to:jery_lee(jery)
现在所说的任何组建，都是和结构有关系，ejb是和数据库结构紧密联系的，所以，所以当数据库结构发生变化，应用发生变化即ejb发生变化是很正常的，现在还没有任何一种类似ejb组建，能作到数据结构变，而应用不变的，你用jdbc，难道数据库结构变了，应用不变吗？并且现在的b/s结构，多用户操作，并发处理相当烦琐，而你用ejb，可以不用管这些，因为事物处理，并发控制，安全访问等，都已经有容器提供了专家级的解决方案。何乐而不为呢？

你选择了ejb，说明你选择了session bean，对于cmp，效率确实较差，而且粒度太细，你肯定不能在系统中，每个表的一行对应一个cmp，尤其是数据量很大的查询，最好不要用cmp，还是用session bean 封装jdbc会好些。

我刚做完一个系统,大部份都是cmp加session bean封装实现,现在速度还可以
不知道以后会不会楼上所说的.关注..........

同意amon_lei(amon) wjmmml(笑着悲伤) ge_yc()的说法d_1979(东东),大数据量的查询就不要用cmp了，确实比session bean慢的，我们做过测试。按数据量的增长，速度基本上以几何级数下降。

的说法不正确，有没有考虑过分布式系统，考虑过动态控制，考虑过数据锁，考虑过事务与并发，考虑过系统安全？就用session bean你自己控制一切？你控制得了？你要写多少代码实现上述的功能？若说你用不到，那就是你的系统规模太小了当你换了一个应用之后，重用性确实不能得到保证。但你自己写的session bean 就不用改动了？ejb是保证了你的context重用性，而不是保证你的商务代码的重用性。cmp速度是慢一点，但是保证了稳定。大系统的稳定性自然是第一位的。速度相对就宽松一点。

其实我感觉ejb的实体bean的优势，说简单了就在容器帮你处理增删改上，对于查询跟本没有必要用ejb。最好用jdbc。
大的系统在要求除了要求效率方面，就是要求稳定性了，所以用cmp更好。可移植性更好。但是缺点是对数据的处理不够灵活。

我认为Entity Bean 的最大优点是将数据的逻辑操作与物理操作相对独立，提高了代码的可移植性，另外系统级的事务和线程管理减轻了开发人员的负担。

根据本人的经验是，大系统中反而不能使用Entity Bean这个怪物，
大系统中可调整性和速度是很重要的，Entity Bean会成为一个很大的困难。
另外Entity Bean的设计愿意就是数据库的逻辑封装，好象和java的一切都
是对象的思路很合，好象和JavaBean的思路很合，但实际上没有多大用途，
一个复杂的东西，再好也不会有普遍的使用。至于在什么事务、并发管理
方面，直接用JDBC操作数据库时，数据库会比J2EE服务器做得更好，不是
Entity Bean的优势。Entity Bean还有一个数据同步的问题，可能带来数据
的不一致，特别是有多个不同的系统存取同一个数据库时。另外Entity Bean
在存取两方面的速度都不如直接用JDBC，我不明白J2EE为什么要引入Entity
Bean这个东西，还是微软高一些，XML数据集和数据库内存映射，概念简单，
用起来方便，实际上的作用和Entity Bean的作用差不多。J2EE再不有大的
突破，前途难料啊。

在我看来，将关系数据数据库中记录/字段的结构映射成对象/成员，根本就是一个错误。数据就是数据，数据库里的一条记录就是一个Map/RowSet/DOM，不管它实际存储的是Employee还是Order还是AccountTransfer

补充一点，之所以会有EntityBean是因为想要用面向对象的方式解决问题；之所以采用面向对象是因为这种方式天然地支持数据抽象、接口与实现分离；之所以要进行数据抽象、接口与实现分离是因为需要将复杂的系统划分为一个个较为简单的、高度内聚的、松散耦合的模块，从而降低软件的开发维护成本，提高软件质量。所以，面向对象不是我们的终极目的，我们的终极目的是降低开发维护成本、提高质量，面向对象只是用数据抽象、分离接口/实现等方式达到这个目的的解决方案*之一*。用存储过程、视图和某些SQL语法扩展，同样可以做到数据抽象、封装、多态，跟关系/对象映射的方式比较起来，唯一的区别就是前者要更加容易，也更加适合关系数据存储的本质特性。

to: wjmmml(笑着悲伤)
当一个应用中有很多个表、很多个字段时，如果全部采用cmp的话就会产生大量的关联、映射关系，本身制作这些映射就是一项繁琐的工作，这些映射虽然清晰的一一对应，但同时也捆绑住了很多东西，所以说那些映射实际上是很死板的，如果你已经建立好了映射，编写好了程序，此时需要改动一个数据表的一个字段名或者是属性，牵连要改动的工作量是相当大的，而且可能还会引起其他的问题。并且如jery_lee说的那样，cmp基本上是没有什么重用性的。虽然我没有真正在大系统中进行实践比较过，但我还是偏向于jery_lee的观点。
以上是我的个人观点，希望大家多提意见。

对于查询，应自己做cache.
对修改，entity bean每次会生成1个Statement，真是浪费性能。
CMP不比BMP快，只是有厂家作了。困难是deploy
大家为什么不讨论一下JDO

其实大家把BMP的entity bean搞懂了，自己知道是否要用它，不要跟着
别人跑，自己要有主见。这样中国的软件事业慢慢才有希望，让实际项目
来选择，自然会留下技术的精华。

同意 object_cat(面向对象的猫)“面向对象不是我们的终极目的，我们的终极目的是降低开发维护成本、提高质量”
to wjmmml(笑着悲伤)我没有用过Entity Bean，只是在J2EE Tutorial 中进行了学习，不过我觉得
entity bean 并没有体现出什么好处，相反由于部署的麻烦性和紧密的藕合性，使得Scalable of Application（灵活性）大大下降，我记得有一本书上面有这样一句话：“简单的使用性是安全系统的灵魂，如果你每天回家要花上3个小时来开门，那你可能不会锁门。”对于要求极高的安全系统尚且如此，那我们的系统有什么理由要做成牵一发而动全身呢？欢迎大家热烈讨论，共同提高！

补充一点，我说的“紧密的藕合性”是指entity bean和数据库表的一一对应
还有其麻烦的部署要求。

我目前的结构是：entiry bean+sesson bean +jsp
entity bean 只是一个表映射实例，比起jsp+JDBC来性能还不错的，因为在我的bean中，每个方法都要连接一次数据库，原来做了个共享池
但是又因为写的连接不能共享，所以没有用了。

调试易

请高手谈谈用Entity Bean 的体会，到底Entity Bean 有什么优势？我觉得它并没有什么优势啊！

解决方案 »