VO、 PO、DO、DTO、 BO、 QO、DAO、POJO在三層架構中的對應位置
https://blog.csdn.net/weixin_40171603/article/details/90709262

 先引用一個VO、 PO、DO、DTO、 BO、DAO、POJO的介紹

來源：https://mp.weixin.qq.com/s/I_DzuoCGjl9SX6VVLoUK0A

PO(persistant object) 持久物件

在 o/r 對映的時候出現的概念，如果沒有 o/r 對映，沒有這個概念存在了。通常對應資料模型 ( 資料庫 ), 本身還有部分業務邏輯的處理。可以看成是與資料庫中的表相對映的 java 物件。最簡單的 PO 就是對應資料庫中某個表中的一條記錄，多個記錄可以用 PO 的集合。 PO 中應該不包含任何對資料庫的操作。

DO（Domain Object）領域物件

就是從現實世界中抽象出來的有形或無形的業務實體。

TO(Transfer Object) ，資料傳輸物件 

在應用程式不同 tie( 關係 ) 之間傳輸的物件

DTO（Data Transfer Object）資料傳輸物件

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

VO(value object) 值物件 

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

BO(business object) 業務物件

從業務模型的角度看 , 見 UML 元件領域模型中的領域物件。封裝業務邏輯的 java 物件 , 通過呼叫 DAO 方法 , 結合 PO,VO 進行業務操作。 business object: 業務物件 主要作用是把業務邏輯封裝為一個物件。這個物件可以包括一個或多個其它的物件。 比如一個簡歷，有教育經歷、工作經歷、社會關係等等。 我們可以把教育經歷對應一個 PO ，工作經歷對應一個 PO ，社會關係對應一個 PO 。 建立一個對應簡歷的 BO 物件處理簡歷，每個 BO 包含這些 PO 。 這樣處理業務邏輯時，我們就可以針對 BO 去處理。

POJO(plain ordinary java object) 簡單無規則 java 物件

純的傳統意義的 java 物件。就是說在一些 Object/Relation Mapping 工具中，能夠做到維護資料庫表記錄的 persisent object 完全是一個符合 Java Bean 規範的純 Java 物件，沒有增加別的屬性和方法。我的理解就是最基本的 Java Bean ，只有屬性欄位及 setter 和 getter 方法！。

DAO(data access object) 資料訪問物件

是一個 sun 的一個標準 j2ee 設計模式， 這個模式中有個介面就是 DAO ，它負持久層的操作。為業務層提供介面。此物件用於訪問資料庫。通常和 PO 結合使用， DAO 中包含了各種資料庫的操作方法。通過它的方法 , 結合 PO 對資料庫進行相關的操作。夾在業務邏輯與資料庫資源中間。配合 VO, 提供資料庫的 CRUD 操作。

三層架構與實體類的關係

下面引用一張圖來源：

https://www.cnblogs.com/whgk/p/6435300.html

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

自己在基礎上補充了部分，來源：https://www.cnblogs.com/zxf330301/p/6534643.html

l         使用者發出請求（可能是填寫表單），表單的資料在展示層被匹配為VO。（前端(vo)—>controller(dto)）

l         展示層把VO轉換為服務層對應方法所要求的DTO，傳送給服務層。(controller(DTO)-->service(BO))

l         服務層首先根據DTO的資料構造（或重建）一個DO，呼叫DO的業務方法完成具體業務。(service(BO)->DO(DO可看做service的部分功能被物件化抽出一部分，好處是面向物件程式設計，，，自己體會))

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

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

VO與DTO區別

 來源：https://www.cnblogs.com/zxf330301/p/6534643.html

       大家可能會有個疑問（在筆者參與的專案中，很多程式設計師也有相同的疑惑）：既然DTO是展示層與服務層之間傳遞資料的物件，為什麼還需要一個VO呢？對！對於絕大部分的應用場景來說，DTO和VO的屬性值基本是一致的，而且他們通常都是POJO，因此沒必要多此一舉，但不要忘記這是實現層面的思維，對於設計層面來說，概念上還是應該存在VO和DTO，因為兩者有著本質的區別，DTO代表服務層需要接收的資料和返回的資料，而VO代表展示層需要顯示的資料。

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

       理論歸理論，這到底還是分析設計層面的思維，是否在實現層面必須這樣做呢？一刀切的做法往往會得不償失，下面我馬上會分析應用中如何做出正確的選擇。

VO與DTO的應用

       上面只是用了一個簡單的例子來說明VO與DTO在概念上的區別，本節將會告訴你如何在應用中做出正確的選擇。

       在以下才場景中，我們可以考慮把VO與DTO二合為一（注意：是實現層面）：

l         當需求非常清晰穩定，而且客戶端很明確只有一個的時候，沒有必要把VO和DTO區分開來，這時候VO可以退隱，用一個DTO即可，為什麼是VO退隱而不是DTO？回到設計層面，服務層的職責依然不應該與展示層耦合，所以，對於前面的例子，你很容易理解，DTO對於“性別”來說，依然不能用“帥哥美女”，這個轉換應該依賴於頁面的指令碼（如JavaScript）或其他機制（JSTL、EL、CSS）

l         即使客戶端可以進行定製，或者存在多個不同的客戶端，如果客戶端能夠用某種技術（指令碼或其他機制）實現轉換，同樣可以讓VO退隱

以下場景需要優先考慮VO、DTO並存：

l         上述場景的反面場景

l         因為某種技術原因，比如某個框架（如Flex）提供自動把POJO轉換為UI中某些Field時，可以考慮在實現層面定義出VO，這個權衡完全取決於使用框架的自動轉換能力帶來的開發和維護效率提升與設計多一個VO所多做的事情帶來的開發和維護效率的下降之間的比對。

l         如果頁面出現一個“大檢視”，而組成這個大檢視的所有資料需要呼叫多個服務，返回多個DTO來組裝（當然，這同樣可以通過服務層提供一次性返回一個大檢視的DTO來取代，但在服務層提供一個這樣的方法是否合適，需要在設計層面進行權衡）。