我对EJB的一点迷惑

Question

第一，EJB应该用于表示细粒度的实体对象，而client与server之间的交互原本就不应该通过entity bean，应该由service层组装粗粒度的DTO传递给client。同样的原因，entity bean之间也不会有更多的交流（除了对象模型固有的关联），都应该由service层来处理。第二，以你举的例子，在交易动作完成以后，entity bean记载的信息就应该进入数据库，entity bean本身则应该被销毁。第三，我一直觉得，CMP存在的价值就是（与session bean一道）提供分布式能力。如果没有分布的要求，基于POJO的ORM（譬如Hibernate和JDO）要好得多。

Answer 1

多谢Schlemiel(维特根斯坦的扇子)的回答，讲得不错。    在第二点中，entity是应该被销毁，可是这个时机是怎样决定的呢,假如我有大量并发用户，前面的entity bean还没有被销毁，后面的又生成了新的entity bean,岂不是很浪费资源。如果能够知道容器管理生命周期的调度细节，相信在工作中应该有不少帮助，可是找不到这样的资料。
    第三点你真是提醒了我，呵呵    还有就是我引用了IBM一个人写的J2EE Pitfalls and Best Pratics文章中的一段话：“Kyle Brown 谈到一个案例(1) ：用户设定系统中的每一个对象是一个 entity bean超过 200 个entity EJB’s,在服务器启动的时候要花费好几个小时，他建议用户用session bean，返回简单的 Java 对象减少到 20 多个entity beans服务器启动时间不超过一分钟”，一直搞不懂他这段话的含义，这里数字应该指的是EJBs的种类吧。是不是能够使用POJO的地方尽量使用POJO,而不是CMP.
多谢！

Answer 2

第二点，entity在销毁时不是销毁这个实例，只是load

Answer 3

一点愚见：
第二点:对于CMP，钝化的时刻由容器决定，对于BMP，则要手写
由于有实例池的存在，如果一个用户实例了一个实体BEAN，当第二个用户也需要同一个实例时，容器会先在池内寻找看有没有该实例存在，如果有，则直接使用，若无，则会新实例化一个

Answer 4

我对EJB并不熟悉，泛泛而谈也没什么意思，第二个问题就不再参与了，单就第三个问题再多说几句。与Hibernate之类基于POJO的ORM相比，entity bean的优势是显而易见的：自动提供的分布和负载均衡能力。所以，如果需要给J2EE应用提供分布式能力，entity bean将是首选（甚至可能是唯一选择）。但是entity bean的劣势也同样明显，那就是复杂和重量级，对于小规模、非分布的应用，无端地引入一个如此庞大的体系显然是很不划算的。楼主后面提的这个问题其实很有意思：我很难想象任何一个应用系统能涉及200种实体（在逻辑上），但拥有200种entity bean class，给人的感觉却是理所应当，只不过是规模扩大的正常现象而已。实际上，这个问题很大程度上并不是EJB的问题，它来源于对象模型与关系模型之间固有的“阻抗不匹配”。即便使用其他的ORM方案，你同样会遇到这个问题。很多时候我们会说，OLTP是适合用ORM的。但是，同样是OLTP，有些系统中出现的实体却不是那么“实在”。举个例子吧，一个工商系统用的电子政务网站，企业可以到这个网站上办理手续，填写表格。很自然地，我们会把一份表格设计为一个实体。但是，这将是一个典型的“不实在”的实体：它的各个属性（例如企业名称、企业注册资金数、对外投资情况……）并没有一定的理由要出现在一起，只不过是工商局要求看这些信息而已。这种实体有一个典型的特征：从数据库通过ORM变成实体，再从实体通过service变成DTO，它们的字段几乎不会有任何变化（因为页面上要展示的恰好就是实体所拥有的字段）。有时我就会想，这种实体真的有成其为实体的理由吗？使用这样生硬的实体（譬如“广告经营单位基本情况表”实体），如何能够不让实体数量快速膨胀？这不是一个答案，是我也在思考的问题。

Answer 5

我的MSN是[email protected]
QQ是16951832,希望能够和你们交流一下