推荐一种EJB设计模式

/**
* 此文从重粒子空间转而来，已经原作者的同意
* 在看此文前，请先看Sun的一篇文章
* http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/
*/
//----------------------------------------原文发下
呵呵，我试试，我的表述和组织能力不是很好 ^o^
--------------------------------------------------------------------------------
【老实和尚】 于 2001-4-11 10:09:07 加贴在 重粒子空间 ↑
/**
* 过一阵会忘记的倒可能不会，因为毕竟做得太多，但将它能写出来，倒是能将思* 路更清晰些，但真正让我动笔，却是因为重粒子相邀
*/
在这里肯定是 EntityBean了[无论是BMP还是CMP都是可行的，因为在这里已经不是讨论EntityBean居竟如何实现这一层，而是它如何面向它的Client端(一般是application,javaBean等)，给它的client端以什么方法去使用的问题]
题外话：由此而产生的其它好处是我始料未及的，这已经超出了上边的文章的所介绍的好处，这也是我为什么要推荐它的原因
上边这篇文章介绍了三种模式
第一种模式[Using Separate Methods to Access Individual Attributes]
就不用多说，一个EntityBean,你得到一个Remote Interface后想怎么就怎么，看起来很自由，但比如，你的 EntityBean有30个字段/属性，如果你想更新其中的18个字段（这种要求我想是很常见的），你不得不用你的Remote.setXXX()18次，这可是18次远程访问，除非你确定你的client端和你的server端是在同一个container中，否则即使你的client端和你的EntityBean在同一台机器，在同一个application内，它也是RemoteCall，因为对于container来说，它是Remote,照sun的说法，Remote Call是expensive，将加重你的server的负担，这我们能理解吧。
这种模式还有第二个更严重的弊端，就是Transaction不能保证，在你的client的一个方法中Remote.setXXX()18次，其中任何一次均可能发生错误而中断（如你的数据过长…），但你却无法保证它的事务Rollback，除非你手写代码来保证，如果你真这么做，我想bea公司的人会落泪，那可是20000美金的东东呵，被人束之高阁，所以，在clien端再写transaction是不可取的。
那我们如何解决它呢，用第二种模式Using a Value Object for All Attributes
将所有的字段抽象成一个对象
用一句话来描述它的，在上一种模式中，你是在你的client端分18次将你的属性set给EntityBean，而在这种模式你是在你的client端先将你的所有属性(30种)全设置好，已经构造了一个Model（就是你的EntityBean抽象出来的一个普通的类，如果不明白，看一下文章就应该知道了），在你的client端只要调用一个Remote方法，如Remote.updateMember(Model myModel),这个方法传进去的是一个完整的对象，而不是一个一个的属性，俗点说，就是"打包上传" ^o^，性能的好处就不说了，具体实现参考文章中有，也不多说