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來取代，但在服務層提供一個這樣的方法是否合適，需要在設計層面進行權衡）。