/**
* 此文從重粒子空間轉而來，已經原作者的同意
* 在看此文前，請先看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^，性能的好處就不說了，具體實現參考文章中有，也不多說
