DO 用到的不多，有一種情況是微服務之間互相傳輸對象數(shù)據(jù)的時候，我們會將該數(shù)據(jù)抽取出來。

比如商品下單以后，大量的 JSON 數(shù)據(jù)會傳輸?shù)胶笈_，我們會在后臺調(diào)用很多模塊，比如 OMS/訂單管理模塊，又或是 ERP 模塊，又或是 WMS/庫存物流模塊等，會調(diào)用很多其他微服務模塊。不同服務之間傳輸對象，就可以將對象定義為 DO 或者 TO（Transfer Object），不同叫法而已。然后兩個模塊之間 RPC 調(diào)用，傳輸?shù)膶ο笠粌蓚€模塊共享，一種是將每一個模塊涉及的各種實體對象單獨抽出來放在一個 Entity 模塊下；還一種是將這些微服務模塊之間的交互傳輸對象定義在 Common 模塊中，作為 DO 或 TO 來進行微服務之間的數(shù)據(jù)傳輸。

2.8. AO（Application Object）

AO 對象全稱為 Application Object（應用對象），在 Web 層與 Service 層之間抽象的復用對象模型，極為貼近展示層，復用度不高。舉一個很簡單的例子：控制層（Controller） 在業(yè)務邏輯層（Service）查詢一條或多條數(shù)據(jù)，這個數(shù)據(jù)的傳輸過程的運載就是 AO 完成。在正常的業(yè)務邏輯中一般都有很多種類型的數(shù)據(jù)，例如 整形、字符型、集合、類 等，我們把它統(tǒng)稱為 AO。

2.9. DAO（Data Access Object）

DAO 對象全稱為 Data Access Object（數(shù)據(jù)訪問對象），是主要封裝對數(shù)據(jù)庫的訪問。通過它可以把 POJO 持久化為 PO，用 PO 組裝出 VO 和 DTO。DAO 一般在持久層，完全封裝數(shù)據(jù)庫操作，對外暴露的方法的使得上層不需要關注數(shù)據(jù)庫的相關信息，只需要插入、刪除、更新、查詢即可。

例如 UserDao 封裝的就是對 user 表的增刪改查操作：

三. 區(qū)別和應用

3.1. VO 與 DTO 的區(qū)別

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

DTO 代表服務層需要接收的數(shù)據(jù)和返回的數(shù)據(jù)，而 VO 代表展示層需要顯示的數(shù)據(jù)。用一個例子來說明可能會比較容易理解：例如服務層有一個 getUser 的方法返回一個系統(tǒng)用戶，其中有一個屬性是 gender（性別），對于服務層來說，它只從語義上定義：1-男性，2-女性，0-未指定，而對于展示層來說，它可能需要用“帥哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。說到這里，可能你還會反駁，在服務層直接就返回“帥哥美女”不就行了嗎？對于大部分應用來說，這不是問題，但設想一下，如果需求允許客戶可以定制風格，而不同風格對于“性別”的表現(xiàn)方式不一樣，又或者這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現(xiàn)層的要求有所不同，那么，問題就來了。

    再者，回到設計層面上分析，從職責單一原則來看，服務層只負責業(yè)務，與具體的表現(xiàn)形式無關，因此，它返回的 DTO，不應該出現(xiàn)與表現(xiàn)形式的耦合。理論歸理論，這到底還是分析設計層面的思維，是否在實現(xiàn)層面必須這樣做呢？一刀切的做法往往會得不償失，下面我馬上會分析應用中如何做出正確的選擇。

3.2. VO 與 DTO 的應用

上面只是用了一個簡單的例子來說明 VO 與 DTO 在概念上的區(qū)別，本節(jié)將會告訴你如何在應用中做出正確的選擇。在以下場景中，我們可以考慮把 VO 與 DTO 二合為一（注意，是實現(xiàn)層面）：

• 需求非常清晰穩(wěn)定，而且客戶端很明確只有一個的時候，沒有必要把 VO 和 DTO 區(qū)分開來，這時候 VO 可以退隱，用一個 DTO 即可，為什么是 VO 退隱而不是 DTO？回到設計層面，服務層的職責依然不應該與展示層耦合，所以，對于前面的例子，你很容易理解，DTO 對于“性別”來說，依然不能用“帥哥美女”，這個轉(zhuǎn)換應該依賴于頁面的腳本（如 JavaScript）或其他機制（JSTL、EL、CSS）；
• 即使客戶端可以進行定制，或者存在多個不同的客戶端，如果客戶端能夠用某種技術(shù)（腳本或其他機制）實現(xiàn)轉(zhuǎn)換，同樣可以讓 VO 退隱。

以下場景需要優(yōu)先考慮 VO、DTO 并存：

• 上述場景的反面場景；
• 因為某種技術(shù)原因，比如某個框架（如 Flex）提供自動把 POJO 轉(zhuǎn)換為 UI 中某些 Field 時，可以考慮在實現(xiàn)層面定義出 VO，這個權(quán)衡完全取決于使用框架的自動轉(zhuǎn)換能力帶來的開發(fā)和維護效率提升，與設計多一個 VO 所多做的事情帶來的開發(fā)和維護效率的下降之間的比對。
• 如果頁面出現(xiàn)一個“大視圖”，而組成這個大視圖的所有數(shù)據(jù)需要調(diào)用多個服務，返回多個DTO 來組裝（當然，這同樣可以通過服務層提供一次性返回一個大視圖的 DTO 來取代，但在服務層提供一個這樣的方法是否合適，需要在設計層面進行權(quán)衡）。 

3.3. DTO 與 DO 的區(qū)別

    首先是概念上的區(qū)別，DTO 是展示層和服務層之間的數(shù)據(jù)傳輸對象（可以認為是兩者之間的協(xié)議），而 DO 是對現(xiàn)實世界各種業(yè)務角色的抽象，這就引出了兩者在數(shù)據(jù)上的區(qū)別，例如 UserInfo和 User，對于一個 getUser 方法來說，本質(zhì)上它永遠不應該返回用戶的密碼，因此 UserInfo 至少比 User 少一個 password 的數(shù)據(jù)。而在領域驅(qū)動設計中，DO 不是簡單的 POJO，它具有領域業(yè)務邏輯。

3.4. DTO 與 DO 的應用

從上一節(jié)的例子中，細心的讀者可能會發(fā)現(xiàn)問題：既然 getUser 方法返回的 UserInfo 不應該包含 password，那么就不應該存在 password 這個屬性定義，但如果同時有一個 createUser 的方法，傳入的 UserInfo 需要包含用戶的 password，怎么辦？在設計層面，展示層向服務層傳遞的DTO 與服務層返回給展示層的 DTO 在概念上是不同的，但在實現(xiàn)層面，我們通常很少會這樣做（定義兩個 UserInfo，甚至更多），因為這樣做并不見得很明智，我們完全可以設計一個完全兼容的 DTO，在服務層接收數(shù)據(jù)的時候，不該有展示層設置的屬性（如訂單的總價應該由其單價、數(shù)量、折扣等決定），無論展示層是否設置，服務層都一概忽略，而在服務層返回數(shù)據(jù)時，不該返回的數(shù)據(jù)（如用戶密碼），就不設置對應的屬性。

對于 DO 來說，還有一點需要說明：為什么不在服務層中直接返回 DO 呢？這樣可以省去 DTO 的編碼和轉(zhuǎn)換工作，原因如下：

• 兩者在本質(zhì)上的區(qū)別可能導致彼此并不一一對應，一個 DTO 可能對應多個 DO，反之亦然，甚至兩者存在多對多的關系。
• DO 具有一些不應該讓展示層知道的數(shù)據(jù)。
• DO 具有業(yè)務方法，如果直接把 DO 傳遞給展示層，展示層的代碼就可以繞過服務層直接調(diào)用它不應該訪問的操作，對于基于 AOP 攔截服務層來進行訪問控制的機制來說，這問題尤為突出，而在展示層調(diào)用 DO 的業(yè)務方法也會因為事務的問題，讓事務難以控制。
• 對于某些 ORM 框架（如 Hibernate）來說，通常會使用“延遲加載”技術(shù)，如果直接把 DO 暴露給展示層，對于大部分情況，展示層不在事務范圍之內(nèi)（Open session in view 在大部分情況下不是一種值得推崇的設計），如果其嘗試在 Session 關閉的情況下獲取一個未加載的關聯(lián)對象，會出現(xiàn)運行時異常（對于 Hibernate 來說，就是 LazyInitiliaztionException）。
• 從設計層面來說，展示層依賴于服務層，服務層依賴于領域?qū)?，如果?DO 暴露出去，就會導致展示層直接依賴于領域?qū)?，這雖然依然是單向依賴，但這種跨層依賴會導致不必要的耦合。

    對于 DTO 來說，也有一點必須進行說明，就是 DTO 應該是一個“扁平的二維對象”，舉個例子來說：如果 User 會關聯(lián)若干個其他實體（例如 Address、Account、Region 等），那么 getUser() 返回的 UserInfo，是否就需要把其關聯(lián)的對象的 DTO 都一并返回呢？如果這樣的話，必然導致數(shù)據(jù)傳輸量的大增，對于分布式應用來說，由于涉及數(shù)據(jù)在網(wǎng)絡上的傳輸、序列化和反序列化，這種設計更不可接受。如果 getUser 除了要返回 User 的基本信息外，還需要返回一個 AccountId、AccountName、RegionId、RegionName，那么，請把這些屬性定義到 UserInfo 中，把一個“立體”的對象樹“壓扁”成一個“扁平的二維對象”，筆者目前參與的項目是一個分布式系統(tǒng)，該系統(tǒng)不管三七二十一，把一個對象的所有關聯(lián)對象都轉(zhuǎn)換為相同結(jié)構(gòu)的 DTO 對象樹并返回，導致性能非常的慢。

3.5. DO 與 PO 的區(qū)別

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

• DO 在某些場景下不需要進行顯式的持久化，例如利用策略模式設計的商品折扣策略，會衍生出折扣策略的接口和不同折扣策略實現(xiàn)類，這些折扣策略實現(xiàn)類可以算是 DO，但它們只駐留在靜態(tài)內(nèi)存，不需要持久化到持久層，因此，這類 DO 是不存在對應的 PO 的。
• 同樣的道理，某些場景下，PO 也沒有對應的 DO，例如老師 Teacher 和學生 Student 存在多對多的關系，在關系數(shù)據(jù)庫中，這種關系需要表現(xiàn)為一個中間表，也就對應有一個TeacherAndStudentPO 的 PO，但這個 PO 在業(yè)務領域沒有任何現(xiàn)實的意義，它完全不能與任何 DO 對應上。這里要特別聲明，并不是所有多對多關系都沒有業(yè)務含義，這跟具體業(yè)務場景有關，例如：兩個 PO 之間的關系會影響具體業(yè)務，并且這種關系存在多種類型，那么這種多對多關系也應該表現(xiàn)為一個 DO，又如：“角色”與“資源”之間存在多對多關系，而這種關系很明顯會表現(xiàn)為一個 DO——“權(quán)限”。
• 某些情況下，為了某種持久化策略或者性能的考慮，一個 PO 可能對應多個 DO，反之亦然。例如客戶 Customer 有其聯(lián)系信息 Contacts，這里是兩個一對一關系的 DO，但可能出于性能的考慮（極端情況，權(quán)作舉例），為了減少數(shù)據(jù)庫的連接查詢操作，把 Customer 和Contacts 兩個 DO 數(shù)據(jù)合并到一張數(shù)據(jù)表中。反過來，如果一本圖書 Book，有一個屬性是封面 Cover，但該屬性是一副圖片的二進制數(shù)據(jù)，而某些查詢操作不希望把 Cover 一并加載，從而減輕磁盤 IO 開銷，同時假設 ORM 框架不支持屬性級別的延遲加載，那么就需要考慮把 Cover 獨立到一張數(shù)據(jù)表中去，這樣就形成一個 DO 對應一個 PO 的情況。
• PO 的某些屬性值對于 DO 沒有任何意義，這些屬性值可能是為了解決某些持久化策略而存在的數(shù)據(jù)，例如為了實現(xiàn)“樂觀鎖”，PO 存在一個 version 的屬性，這個 version 對于 DO 來說是沒有任何業(yè)務意義的，它不應該在 DO 中存在。同理，DO 中也可能存在不需要持久化的屬性。

3.6. DO 與 PO 的應用

    由于 ORM 框架的功能非常強大而大行其道，而且 JavaEE 也推出了 JPA 規(guī)范，現(xiàn)在的業(yè)務應用開發(fā)，基本上不需要區(qū)分 DO 與 PO，PO 完全可以通過 JPA、Hibernate Annotations/hbm隱藏在 DO 之中。雖然如此，但有些問題我們還必須注意：

• 對于 DO 中不需要持久化的屬性，需要通過 ORM 顯式的聲明，如：在 JPA 中，可以利用@Transient 聲明。
• 對于 PO 中為了某種持久化策略而存在的屬性，例如 version，由于 DO、PO 合并了，必須在 DO 中聲明，但由于這個屬性對 DO 是沒有任何業(yè)務意義的，需要讓該屬性對外隱藏起來，最常見的做法是把該屬性的 get/set 方法私有化，甚至不提供 get/set 方法，但對于Hibernate 來說，這需要特別注意，由于 Hibernate 從數(shù)據(jù)庫讀取數(shù)據(jù)轉(zhuǎn)換為 DO 時，是利用反射機制先調(diào)用 DO 的空參數(shù)構(gòu)造函數(shù)構(gòu)造 DO 實例，然后再利用 JavaBean 的規(guī)范反射出set 方法來為每個屬性設值，如果不顯式聲明 set 方法，或把 set 方法設置為 private，都會導致 Hibernate 無法初始化 DO，從而出現(xiàn)運行時異常，可行的做法是把屬性的 set 方法設置為 protected。
• 對于一個 DO 對應多個 PO，或者一個 PO 對應多個 DO 的場景，以及屬性級別的延遲加載，Hibernate 都提供了很好的支持，請參考 Hibnate 的相關資料。

四. 實例講解

有一個博客系統(tǒng)，數(shù)據(jù)庫中存儲了很多篇博客。我們會做如下設計：

• 數(shù)據(jù)庫表：表中的博客包括編號、博客標題、博客內(nèi)容、博客標簽、博客分類、博客狀態(tài)、創(chuàng)建時間、修改時間等。
• PO：包括編號、博客標題、博客內(nèi)容、博客標簽、博客分類、博客狀態(tài)、創(chuàng)建時間、修改時間等。（與數(shù)據(jù)庫表中的字段一樣）。
• VO：在客戶端瀏覽器展示的頁面數(shù)據(jù)，博客標題、博客內(nèi)容、博客標簽、博客分類、創(chuàng)建時間、上一篇博客 URL、下一篇博客 URL。
• DTO：在服務端數(shù)據(jù)傳輸?shù)膶ο?，編號、博客標題、博客內(nèi)容、博客標簽、博客分類、創(chuàng)建時間、上一篇博客編號、下一篇博客編號。
• DAO：數(shù)據(jù)庫增刪改查的方法，例如新增博客、刪除博客、查詢所有博客、更新博客。
• BO：基本業(yè)務操作，如管理分類、管理標簽、修改博客狀態(tài)等，是我們常說的 Service 層操作。

• 用戶發(fā)出請求（可能是填寫表單），表單的數(shù)據(jù)在展示層被匹配為 VO。
• 展示層把 VO 轉(zhuǎn)換為服務層對應方法所要求的 DTO，傳送給服務層。
• 服務層首先根據(jù) DTO 的數(shù)據(jù)構(gòu)建或重建一個 DO，調(diào)用 DO 的業(yè)務方法完成具體業(yè)務。
• 服務層把 DO 轉(zhuǎn)換為持久層對應的 PO（可以使用 ORM 工具，也可以不用），調(diào)用持久層的持久化方法，把 PO 傳遞給它，完成持久化操作。
• 對于一個逆向操作，如讀取數(shù)據(jù)，也是用類似的方式轉(zhuǎn)換和傳遞。 

五. 總結(jié)

到目前為止，相信大家都已經(jīng)比較清晰的了解了 VO、DTO、DO、PO、BO 等的概念、區(qū)別和實際應用了。通過上面的詳細分析，我們還可以總結(jié)出一個原則：分析設計層面和實現(xiàn)層面完全是兩個獨立的層面，即使實現(xiàn)層面通過某種技術(shù)手段可以把兩個完全獨立的概念合二為一，在分析設計層面，我們?nèi)匀唬ㄖ辽僭陬^腦中）需要把概念上獨立的東西清晰的區(qū)分開來，這個原則對于做好分析設計非常重要（工具越先進，往往會讓我們越麻木）。

到此這篇關于Java中POJO、VO、DO、DTO、PO、BO、AO、DAO的概念和區(qū)別以及如何應用的文章就介紹到這了,更多相關POJO、VO、DO、DTO、PO、BO、AO、DAO應用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！