http://www.shaoqun.com/a/118973.aspx

經常會接觸到VO，DO，DTO的概念，本文從領域建模中的實體劃分和專案中的實際應用情況兩個角度，對這幾個概念進行簡析。

得出的主要結論是：在專案應用中，VO對應於頁面上需要顯示的資料（表單），DO對應於資料庫中儲存的資料（資料表），DTO對應於除二者之外需要進行傳遞的資料。

一、實體類

百度百科中對於實體類的定義如下：

實體類的主要職責是儲存和管理系統內部的資訊，它也可以有行為，甚至很複雜的行為，但這些行為必須與它所代表的實體物件密切相關。

根據以上定義，我們可以瞭解到，實體類有兩方面內容，儲存資料和執行資料本身相關的操作。這兩方面內容對應到實現上，最簡單的實體類是POJO類，含有屬性及屬性對應的set和get方法，實體類常見的方法還有用於輸出自身資料的toString方法。

二、領域模型中的實體類

領域模型中的實體類分為四種類型：VO、DTO、DO、PO，各種實體類用於不同業務層次間的互動，並會在層次內實現實體類之間的轉化。

業務分層為：檢視層（VIEW+ACTION），服務層（SERVICE），持久層（DAO）

相應各層間實體的傳遞如下圖：

專案中我們並沒有嚴格遵循這種傳遞關係，但這種和業務層次的關聯對我們理解各實體類的作用是有幫助的。（我們沒有接觸到PO的原因，我理解為ORM對PO進行了封裝）

以下是資料的原文，上圖是基於此繪製的：

概念：

VO（ViewObject）：檢視物件，用於展示層，它的作用是把某個指定頁面（或元件）的所有資料封裝起來。

DTO（Data TransferObject）：資料傳輸物件，這個概念來源於J2EE的設計模式，原來的目的是為了EJB的分散式應用提供粗粒度的資料實體，以減少分散式呼叫的次數，從而提高分散式呼叫的效能和降低網路負載，但在這裡，我泛指用於展示層與服務層之間的資料傳輸物件。

DO（DomainObject）：領域物件，就是從現實世界中抽象出來的有形或無形的業務實體。

PO（PersistentObject）：持久化物件，它跟持久層（通常是關係型資料庫）的資料結構形成一一對應的對映關係，如果持久層是關係型資料庫，那麼，資料表中的每個欄位（或若干個）就對應PO的一個（或若干個）屬性。

模型：

      下面以一個時序圖建立簡單模型來描述上述物件在三層架構應用中的位置

l        使用者發出請求（可能是填寫表單），表單的資料在展示層被匹配為VO。

l        展示層把VO轉換為服務層對應方法所要求的DTO，傳送給服務層。

l        服務層首先根據DTO的資料構造（或重建）一個DO，呼叫DO的業務方法完成具體業務。

l        服務層把DO轉換為持久層對應的PO（可以使用ORM工具，也可以不用），呼叫持久層的持久化方法，把PO傳遞給它，完成持久化操作。

l        對於一個逆向操作，如讀取資料，也是用類似的方式轉換和傳遞，略。

三、專案中的實體類

專案中常見的實體類有VO，DO和DTO，命名規則也常是以相應字串結尾，如*VO.Java。但是DTO不總是遵循這個規則，而通常與他的用途有關，如寫成*Query.java，表示儲存了一個查詢條件。專案中實體類出現的業務層次也沒有這麼嚴格，例如我們可以在檢視層就組裝一個DO，也可以將一個VO從持久層傳出來，所以與業務分層相關聯的劃分方法顯得有些冗餘。從專案程式碼中抽象出的理解是：VO對應於頁面上需要顯示的資料，DO對應於資料庫中儲存的資料，DTO對應於除二者之外需要進行傳遞的資料。