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