轉自
portian基本上一個應用程序里面的領域相關的模型里面需要3種對象：
1。值對象(Value Object)，
沒有身份，內容表示一切，譬如我和weihello都去銀行里面存取100大洋，那這個100RMB是一個值對象
2。實體對象（Entity)，
需要持久，不是按照內容，
而是按照它的身份來區分，也就是說即使內容完全一樣，也不是同一個對象。這個身份在內存
里面是它的實例地址，在數據庫里面是關鍵字，最常見的就是OID.這個實體對象并不是純數據，它處理本身的實體模型，例如Accout，它的
withDraw,它的子Account等等，
它也處理自己和其他實體對象之間的關系，例如訂單里面的訂單行，都是應該在這個Account里面實現的，
而不應該有一個什么控制類。在一個Web應用程序里面，涉及到對象關系的一般只需要一個（或幾個）DTOFactory負責所有對象的DTO和
Entity之間的組裝和拆份，不需要專門的管理，這一部分也是和數據建模最相近的地方。
?
3。服務對象(Service)，這是為我們提供服務的類，譬如銀行里面服務員，她幫助我們把錢從一個賬戶轉到另外一個賬戶，并記錄相應的交易。
對象的作用是對它自己的內部狀態負責，如果它需要存取很多其它對象的狀態進行運算，那叫做特性忌妒，是要重構的。應該把這些代碼移到那個持有這些狀態的類里面
辨別一些名詞：
1。VO：實際上很模糊，通常指ValueObject和ViewObject
2. ViewObject，界面展現需要的對象，如Struts的FormBean
3。Value Object，早期被作為ValueObject和Transfer Object的總稱。實際上Value Object的真正意義在于它的內容，而不是身份
4。Transfer Object：數據傳輸對象，在應用程序不同層次之間傳書對象，在一個分布式應用程序中，通常可以提高整體的性能
5。PO：也許就是Persistent Object，基本上就是Entity了
在不同的體系結構和實現方式里面，這些對象有可能重復，也有可能不重疊。如果你要做一個對所有的體系都能夠方便移植的框架，那么每一種對象都需要
嚴格區分。例如JDO的PO不能作為TO，應為它不能脫離PM，譬如你可以選擇用ViewObject（如Struts的FOrmBean)直接作為
TO，但在tapestry和Webwork里面就不合適了。但在很多時候，能夠方便實用是最重要的，不要過度設計就是了。