首先聲明偶也不是什麼高手，以下總結都是自己的體會。不對之處請您多指教。
PO：
persistant object持久對象
最形象的理解就是一個PO就是數據庫中的一條記錄。
好處是可以把一條記錄作爲一個對象處理，可以方便的轉爲其它對象。
BO：
business object業務對象
主要作用是把業務邏輯封裝爲一個對象。這個對象可以包括一個或多個其它的對象。
比如一個簡歷，有教育經歷、工作經歷、社會關係等等。
我們可以把教育經歷對應一個PO，工作經歷對應一個PO，社會關係對應一個PO。
建立一個對應簡歷的BO對象處理簡歷，每個BO包含這些PO。
這樣處理業務邏輯時，我們就可以針對BO去處理。
VO ：
value object值對象
ViewObject表現層對象
主要對應界面顯示的數據對象。對於一個WEB頁面，或者SWT、SWING的一個界面，用一個VO對象對應整個界面的值。
DTO ：
Data Transfer Object數據傳輸對象
主要用於遠程調用等需要大量傳輸對象的地方。
比如我們一張表有100個字段，那麼對應的PO就有100個屬性。
但是我們界面上只要顯示10個字段，
客戶端用WEB service來獲取數據，沒有必要把整個PO對象傳遞到客戶端，
這時我們就可以用只有這10個屬性的DTO來傳遞結果到客戶端，這樣也不會暴露服務端表結構.到達客戶端以後，如果用這個對象來對應界面顯示，那此時它的身份就轉爲VO
POJO ：
plain ordinary java object 簡單ava對象
個人感覺POJO是最參見最多變的對象，是一箇中間對象，也是我們最常打交道的對象。
一個POJO持久化以後就是PO
直接用它傳遞、傳遞過程中就是DTO
直接用來對應表示層就是VO
DAO：
data access object數據訪問對象
這個大家最熟悉，和上面幾個O區別最大，基本沒有互相轉化的可能性和必要.
主要用來封裝對數據庫的訪問。通過它可以把POJO持久化爲PO，用PO組裝出來VO、DTO
總結下我認爲一個對象究竟是什麼O要看具體環境，在不同的層、不同的應用場合，對象的身份也不一樣，而且對象身份的轉化也是很自然的。就像你對老婆來說就是老公，對父母來說就是子女。設計這些概念的初衷不是爲了唬人而是爲了更好的理解和處理各種邏輯，讓大家能更好的去用面向對象的方式處理問題.
大家千萬不要陷入過度設計，大可不必爲了設計而設計一定要在代碼中區分各個對象。一句話技術是爲應用服務的。
歡迎指正。
理清了上述概念，好，我們就開始討論，爲什麼需要它們，爲什麼不需要它們。首先說PO和VO吧，它們的關係應該是相互獨立的，一個VO可以只是PO的部分，也可以是多個PO構成，同樣也可以等同於一個PO（當然我是指他們的屬性）。正因爲這樣，PO獨立出來，數據持久層也就獨立出來了，它不會受到任何業務的干涉。又正因爲這樣，業務邏輯層也獨立開來，它不會受到數據持久層的影響，業務層關心的只是業務邏輯的處理，至於怎麼存怎麼讀交給別人吧！不過，另外一點，如果我們沒有使用數據持久層，或者說沒有使用hibernate，那麼PO和VO也可以是同一個東西，雖然這並不好。其次，讓我們看看FormBean和VO，如果簡單地講，我們是可以不需要FormBean的，它只是struts帶來的一部分，而VO是無論如何不能捨棄的。如果讓FormBean直接到業務層（它本來應該生活在控制層），那麼會帶來什麼？View和Model就出現了強耦合，如果想改一下view的表示，整個業務邏輯都得改，恐怖的事情啊！
這些對象概念的出現其實就是體現了一種層的思維，也是體現了一種框架的思維，在層與層之間我們需要什麼？我們應該怎麼通信，其實大家認真地用筆畫上幾個圖就可以知道了。做web應用尤其是企業應用，切忌像樓上某些朋友說的，一個東東從頭到尾，那是非常低劣和錯誤的設計。我們不要單純地就爲了某些對象去爭論什麼，它們更多的只是思維。這樣的思維給我們帶來了哪些好處，不言自明，當然，我們也不得不否認，我們因此失去了某些東西，比如局部的性能或者繁瑣的代碼和調用過程，只是自己衡量一下，它是否值得。
畫了個圖，感覺沒有完全表達出自己的意思。。。。。誰幫忙完善下，最好能體現各個O在MVC中的位置
