網(wǎng)上一大堆關(guān)于PO，POJO，DTO，VO等等對象的討論，通常都是各持己見，公說公有理，婆說婆有理，討論到最后也沒有什么定論。今天看到一個應(yīng)用的代碼，發(fā)現(xiàn)其講PO直接做為VO（view object）在表示層使用。只從代碼上講，這樣做確實省去了跟多操作。不用重復(fù)的做對象的賦值、構(gòu)造。但是會過頭來看，這樣無疑增加了代碼的耦合性。做一個簡單的假設(shè)，如果對持久層的PO進行了修改，相應(yīng)的使用PO做為對應(yīng)的VO（value object）業(yè)務(wù)邏輯層和使用PO最為VO（view object）的表示層都必須做相應(yīng)的修改，如此的應(yīng)用給代碼的維護帶來了很大的負(fù)擔(dān)，可謂是一動則百動。
    在J2EE應(yīng)用開發(fā)中，是不應(yīng)該出現(xiàn)這中PO共享使用的方式的。實體對象不應(yīng)該被跨層使用，各層維護自己的實體對象。這點看書我想大家都知道，而在實際應(yīng)用中很多人都選擇不遵循這一規(guī)則。（在使用hibernate時有所不同，引用：“不過由于Hibernate的強大功能，例如動態(tài)生成PO，PO的狀態(tài)管理可以脫離Session，使得在應(yīng)用了Hibernate的J2EE框架中，PO完全可以充當(dāng)VO，因此我們下面把PO和VO合并，統(tǒng)稱為PO。”引文：結(jié)合struts和hibernate談J2EE架構(gòu)的數(shù)據(jù)表示。）出現(xiàn)這總現(xiàn)象，我想原因只有一個就是貪圖了一時的省事，在一次性應(yīng)用開發(fā)中，相對的業(yè)務(wù)對象改動可能性相當(dāng)?shù)纳伲芏鄷r候在做項目的時候并不會出現(xiàn)預(yù)料不到的改變，沒有必要去管理一大堆各式各樣的實體對象，這樣就自然的導(dǎo)致了PO在各層中共享使用。可是就我目前接觸到的項目基本上沒有需求是如此明確的，通常需求都是在不斷的改變，甚至有時到了最后發(fā)版的時候，一些客戶都會提出修改需求的要求。另外就是自做需求的情況就更是如此了，這種項目的需求是不斷的在變化的。為了保證項目的適應(yīng)性和可擴展性，就必須保證各層之間的相對獨立，盡可能降低耦合度。