淺談對於DAO、PO、POJO、VO、DTO的理解
今天寫後端介面遇到了用VO的情況，於是搜尋了一下相關知識，寫了一篇小博文
參考文件：https://www.cnblogs.com/java-class/p/5439646.html#_labelTop
一般通用的體系如下圖：
第 1 個：DAO
DAO（Data Access Object）資料訪問物件，它是一個面向物件的資料庫介面，負責持久層的操作，為業務層提供介面，主要用來封裝對資料庫的訪問，常見操作無外乎 CURD。我們也可以認為一個 DAO 對應一個 POJO 的物件，它位於業務邏輯與資料庫資源中間，可以結合 PO 對資料庫進行相關的操作。
第 2 個：PO
PO（Persistent Object）持久層物件，它是由一組屬性和屬性的get
set方法組成，最簡單的 PO 就是對應資料庫中某個表中的一條記錄（也就是說，我們可以將資料庫表中的一行理解為一個持久層物件），多個記錄可以用 PO 的集合，PO 中應該不包含任何對資料庫的操作。PO 的屬性是跟資料庫表的欄位一一對應的，此外 PO 物件需要實現序列化介面。在專案中，前端傳來了一個不屬於PO的屬性，如果用@TableField(exist = false)來標註（持久層框架用Mybatis_Plus)，則顯得不規範，可以構造一個VO類，用於業務層資料傳遞。
第 3 個：BO
BO（Business Object）業務層物件，是簡單的真實世界的軟體抽象，通常位於中間層。BO 的主要作用是把業務邏輯封裝為一個物件，這個物件可以包括一個或多個其它的物件。舉一個求職簡歷的例子，每份簡歷都包括教育經歷、專案經歷等，我們可以讓教育經歷和專案經歷分別對應一個 PO，這樣在我們建立對應求職簡歷的 BO 物件處理簡歷的時候，讓每個 BO 都包含這些 PO 即可。暫時專案上沒有接觸過，不好理解。
第 4 個：VO
VO（Value Object）值物件，通常用於業務層之間的資料傳遞，和 PO 一樣也是僅僅包含資料而已，但 VO 應該是抽象出的業務物件，可以和表對應，也可以不對應，這根據業務的需要。 如果鍋碗瓢盆分別為對應的業務物件的話，那麼整個碗櫃就是一個值物件。此外，VO 也可以稱為頁面物件（View Object），如果稱為頁面物件的話，那麼它所代表的將是整個頁面展示層的物件，也可以由需要的業務物件進行組裝而來。
第 5 個：DTO
DTO（Data Transfer Object）資料傳輸物件，主要用於遠端呼叫等需要大量傳輸物件的地方，比如我們有一個交易訂單表，含有 25 個欄位，那麼其對應的 PO 就有 25 個屬性，但我們的頁面上只需要顯示 5 個欄位，因此沒有必要把整個 PO 物件傳遞給客戶端，這時我們只需把僅有 5 個屬性的 DTO 把結果傳遞給客戶端即可，而且如果用這個物件來對應介面的顯示物件，那此時它的身份就轉為 VO。使用 DTO 的好處有兩個，一是能避免傳遞過多的無用資料，提高資料的傳輸速度；二是能隱藏後端的表結構。常見的用法是：將請求的資料或屬性組裝成一個 RequestDTO，再將響應的資料或屬性組裝成一個 ResponseDTO.
第 6 個：POJO
POJO（Plain Ordinary Java Object）簡單的 Java 物件，實際就是普通的 JavaBeans，是為了避免和 EJB（Enterprise JavaBean）混淆所創造的簡稱。POJO 實質上可以理解為簡單的實體類，其中有一些屬性及其getter和setter方法的類，沒有業務邏輯，也不允許有業務方法，也不能攜帶有connection之類的方法。POJO 是 JavaEE 世界裡面最靈活的物件，在簡單系統中，如果從資料庫到頁面展示都是 POJO 的話，它可以是 DTO；如果從資料庫中到業務處理中都是 POJO 的話，它可以是 BO；如果從資料庫到整個頁面的展示的話，它也可以是 VO.