淺析VO、DTO、DO、PO

概念

VO（View Object）: 視圖對象，主要對應界面顯示的數據對象。對于一個WEB頁面，或者SWT、SWING的一個界面，用一個VO對象對應整個界面的值。

BO（business object）：業務對象，主要作用是把業務邏輯封裝為一個對象。這個對象可以包括一個或多個其它的對象。比如一個簡歷，有教育經歷、工作經歷、社會關系等等。我們可以把教育經歷對應一個PO，工作經歷對應一個PO，社會關系對應一個PO。建立一個對應簡歷的BO對象處理簡歷，每個BO包含這些PO。這樣處理業務邏輯時，我們就可以針對BO去處理。

DTO（Data Transfer Object）：數據傳輸對象，主要用于遠程調用等需要大量傳輸對象的地方。比如我們一張表有100個字段，那么對應的PO就有100個屬性。但是我們界面上只要顯示10個字段，客戶端用WEB service來獲取數據，沒有必要把整個PO對象傳遞到客戶端，這時我們就可以用只有這10個屬性的DTO來傳遞結果到客戶端，這樣也不會暴露服務端表結構.到達客戶端以后，如果用這個對象來對應界面顯示，那此時它的身份就轉為VO。在這里，我泛指用于展示層與服務層之間的數據傳輸對象。

POJO（plain ordinary java object） ：簡單java對象，個人感覺POJO是最常見最多變的對象，是一個中間對象，也是我們最常打交道的對象。一個POJO持久化以后就是PO，直接用它傳遞、傳遞過程中就是DTO，直接用來對應表示層就是VO。（POJO、PO、DTO、VO都是處理流程中的名字，不是PO對應一個POJO，DTO對應一個POJO，VO對應一個POJO在有些情況下PO、DTO、VO是指同一個POJO）

DO（Domain Object) 領域對象，就是從現實世界中抽象出來的有形或無形的業務實體。

PO（Persistent Object）：持久化對象，它跟持久層（通常是關系型數據庫）的數據結構形成一一對應的映射關系，如果持久層是關系型數據庫，那么，數據表中的每個字段（或若干個）就對應PO的一個（或若干個）屬性。最形象的理解就是一個PO就是數據庫中的一條記錄，好處是可以把一條記錄作為一個對象處理，可以方便的轉為其它對象。

具體區別&應用

VO與DTO的區別

大家可能會有個疑問：既然DTO是展示層與服務層之間傳遞數據的對象，為什么還需要一個VO呢？對！對于絕大部分的應用場景來說，DTO和VO的屬性值基本是一致的，而且他們通常都是POJO，因此沒必要多此一舉。但不要忘記這是實現層面的思維，對于設計層面來說，概念上還是應該存在VO和DTO，因為兩者有著本質的區別，DTO代表服務層需要接收的數據和返回的數據，而VO代表展示層需要顯示的數據。

舉個例子

：例如服務層有一個getUser的方法返回一個系統用戶，其中有一個屬性是gender(性別)，對于服務層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會反駁，在服務層直接就返回“帥哥美女”不就行了嗎？對于大部分應用來說，這不是問題，但設想一下，如果需求允許客戶可以定制風格，而不同風格對于“性別”的表現方式不一樣，又或者這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現層的要求有所不同，那么，問題就來了。再者，回到設計層面上分析，從職責單一原則來看，服務層只負責業務，與具體的表現形式無關，因此，它返回的DTO，不應該出現與表現形式的耦合。

VO與DTO的應用

為什么不在服務層中直接返回DO呢？這樣可以省去DTO的編碼和轉換工作，原因如下：

兩者在本質上的區別可能導致彼此并不一一對應，一個DTO可能對應多個DO，反之亦然，甚至兩者存在多對多的關系。

DO具有一些不應該讓展示層知道的數據

DO具有業務方法，如果直接把DO傳遞給展示層，展示層的代碼就可以繞過服務層直接調用它不應該訪問的操作，對于基于AOP攔截服務層來進行訪問控制的機制來說，這問題尤為突出，而在展示層調用DO的業務方法也會因為事務的問題，讓事務難以控制。

從設計層面來說，展示層依賴于服務層，服務層依賴于領域層，如果把DO暴露出去，就會導致展示層直接依賴于領域層，這雖然依然是單向依賴，但這種跨層依賴會導致不必要的耦合。

DTO應該是一個“扁平的二維對象”，舉個例子來說明：如果User會關聯若干個其他實體（例如Address、Account、Region等），那么getUser()返回的UserInfo，是否就需要把其關聯的對象的DTO都一并返回呢？如果這樣的話，必然導致數據傳輸量的大增，對于分布式應用來說，由于涉及數據在網絡上的傳輸、序列化和反序列化，這種設計更不可接受。如果getUser除了要返回User的基本信息外，還需要返回一個AccountId、AccountName、RegionId、RegionName，那么，請把這些屬性定義到UserInfo中，把一個“立體”的對象樹“壓扁”成一個“扁平的二維對象”。

這里說的非常好，DTO和DO交互時，或者DTO直接和PO交互時，DO和PO中非常多的字段，DTO是不使用的，不應該全部帶過來，只需要把DO和PO中需要的字段Copy到DTO中，然后再進行轉換。有的同學為了圖方便，DTO是直接繼承PO或者DO（我之前就這個干過），然后DTO又和PO的字段是一致的，導致通過PO吐出的字段超級多，數據傳輸大不說，關鍵是接口輸出時，一大坨字段，抓不住重點。

DO與PO的區別

DO和PO在絕大部分情況下是一一對應的，PO是只含有get/set方法的POJO，但某些場景還是能反映出兩者在概念上存在本質的區別：

DO在某些場景下不需要進行顯式的持久化，例如利用策略模式設計的商品折扣策略，會衍生出折扣策略的接口和不同折扣策略實現類，這些折扣策略實現類可以算是DO，但它們只駐留在靜態內存，不需要持久化到持久層，因此，這類DO是不存在對應的PO的。

同樣的道理，某些場景下，PO也沒有對應的DO，例如老師Teacher和學生Student存在多對多的關系，在關系數據庫中，這種關系需要表現為一個中間表，也就對應有一個TeacherAndStudentPO的PO，但這個PO在業務領域沒有任何現實的意義，它完全不能與任何DO對應上。

某些情況下，為了某種持久化策略或者性能的考慮，一個PO可能對應多個DO，反之亦然。

舉兩個例子：客戶Customer有其聯系信息Contacts，這里是兩個一對一關系的DO，但可能出于性能的考慮（極端情況，權作舉例），為了減少數據庫的連接查詢操作，把Customer和Contacts兩個DO數據合并到一張數據表中。反過來，“角色”與“資源”之間存在多對多關系，會存放到多張表中，而這種關系很明顯會表現為一個DO——“權限”。

• PO的某些屬性值對于DO沒有任何意義，這些屬性值可能是為了解決某些持久化策略而存在的數據，例如為了實現“樂觀鎖”，PO存在一個version的屬性，這個version對于DO來說是沒有任何業務意義的，它不應該在DO中存在。同理，DO中也可能存在不需要持久化的屬性。

總結：DO和PO是兩個層級的概念，兩者存在一對一、一對多和多對一的關系。這兩個層級的字段，DO不需要包括全部的PO，比如PO中的創建、刪除標記、自動生成的ID等，PO可以不用關注。

總結

以上是生活随笔為你收集整理的VO、DTO、DO、PO的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。