VO該如何設計？

談到VO馬上就會想到與之相關的PO。
PO一般都數據庫的直接映射，如hibernate（當然是個代理類，不細解析）
我以前曾經對VO的使用。
一、直接用hibernate 實體類做VO類型，即PO與VO同屬於同一個類。
二、以前用struts1.1的時候，用formbean作爲VO類，即在hibernate中把PO轉成formbean,讓formbean到前臺展現。

我現在我又有一個新的設計觀點，因爲使用struts2：
把hibernate的實體類作爲父類，VO繼承實體類。
爲什麼這樣做呢，先對之前二種做法的缺點說明一下：
第一種，把實體類又作爲VO類，即把UI層特殊的展示需要增加實體的域來體現，這樣就相關於弄髒了原來純淨的實體，如果採用分層開發話，web開發人員與後臺業務開發人員相關把同一個java類不停的更改，時間久了很難管理。
第二種，採用struts1或者在webwork,struts2中增加一個與實體一樣的java類做爲vo,這樣做是一點問題沒有，不過大部份情況下po,vo各內容完全一樣，或者大部份一樣，再去寫一套這樣的一層，更是感覺完全沒有什麼意思，否則webwork,與struts2這樣的web框架弄出來有什麼意思啊，還不如用struts1.
第三個理由是，我在各個層之間之前都是採用實體來進行傳參數，如action->service,saveUser(user),find(user),service->dao...現在這種設計，特別是爲find(user),list(user)等方法，把實體傳進去，然後在dao中組裝在hql,sql或者其它。在做查詢條件時又往往只有實現一個不能滿足能組裝的條件查詢，如user中有一個birthday，如想查詢2003.7 至2004.7之間生日的人，用實體肯定不能把這二個條件包含進去，所以也採用繼承實體來進行處理。

還如一點，如果更需要精細話的設計，那麼也可以把service中傳遞的值繼承實體類，在web中的展現ui的實體承繼service中傳遞值的類