存在即是合理的，業務復雜，人員協同性要求高的場景下，這些規范性的東西不按著來雖然不會出錯，程式照樣跑，但是遵守規范會讓程式更具擴展性和可讀性，都是前輩血淋淋的寶貴經驗，為什么不用？
隨著現在后端編程標準化程度越來越高，各種編程模型層出不窮，作為Java開發人員，大部分人不免要接觸VO，BO，PO，DO，DTO之類的，但很多同學對這些概念一直以來都是云里霧里，團隊開發程序中也總是處于混亂的狀態，抓起來就用，本來是規范性的東西，卻反而導致更加混亂了，
今天我們把這些概念掰開揉碎來講解一下，力求有一個清晰的理解，在開發中能有所助益，文中又理解不到位的，也歡迎大家斧正，
概念
-
VO（
View Object）：視圖物件，用于展示層，它的作用是把某個指定頁面（或組件）的所有資料封裝起來， -
DTO（
Data Transfer Object）：資料傳輸物件，這個概念來源于J2EE的設計模式，原來的目的是為了EJB的分布式應用提供粗粒度的資料物體，以減少分布式呼叫的次數，從而提高分布式呼叫的性能和降低網路負載，但在這里，更符合泛指用于展示層與服務層之間的資料傳輸物件， -
BO（
Business Object）：業務物件，把業務邏輯封裝為一個物件，這個物件可以包括一個或多個其它的物件， -
PO（
Persistent Object）：持久化物件，它跟持久層（通常是關系型資料庫）的資料結構形成一一對應的映射關系，如果持久層是關系型資料庫，那么，資料表中的每個欄位（或若干個）就對應PO的一個（或若干個）屬性， -
DO（
Domain Object）：領域物件，就是從現實世界中抽象出來的有形或無形的業務物體，
如果光看這些概念，可能大部分人都理解，但還是很繞，具體用的時候還是不能很好區分，我們來橫向做個比較，理解會加深一些，
易混點一：VO和DTO
首先VO是最常用的，但對于這個概念，網上也是眾說紛紜，value object 或 view object，一般說視圖物件或者值物件，我更傾向理解為視圖物件，說白了它就是展示用的，不管展示方式是網頁，還是客戶端，還是APP，只要是這個東西是讓人看到的，我們就把它封裝為VO，
VO比較容易混淆的是DTO，DTO是展示層與服務層之間傳遞資料的物件，可以這樣說，對于絕大部分的應用場景來說，DTO和VO的屬性值基本是一致的，而且他們通常都是POJO，那么既然有了VO，為什么還需要DTO呢？
我們舉例來說明一下：
某公司有一個后臺服務，服務層有一個getUser的方法回傳一個系統用戶，包含sex(性別)、年齡，對于服務層來說，DTO只從語意上定義，可能是這樣的：
{
"gender":"男",
"age":35
}
但這個服務同時供多個客戶端使用（不同門戶），而不同的客戶端對于表現層的要求有所不同，比如管理端要求顯示準確的年齡，而應用端為了保護客戶隱私，只需要顯示一個年齡段即可，
管理端VO：
{
"gender":"男",
"age":35
}
應用端VO：
{
"gender":"男",
"age":30~40
}
從這個例子可以看出，DTO很有存在的必要，根據職責單一原則，服務層只負責業務，與具體的表現形式無關，DTO不應該出現與表現形式的耦合，DTO定義的是原始資料，VO再對DTO資料進行解釋，這下VO和DTO用法就清晰很多了，
易混點二：BO和PO
PO是持久物件，這個很好理解，就是物體和資料庫欄位的對應，一個PO的資料結構對應著庫中表的結構，表中的一條記錄就是一個PO屬性，大多數情況下，PO僅僅作為PO只是用來增刪改使用，
PO比較容易混淆的是BO，BO是業務物件，對應的是某個具體的業務塊，可以包含多個屬性、物件，簡單點來說，我們可以把BO看作是PO的組合，
我們舉例來說明一下：
PO-1是交易記錄物件，PO-2是登錄記錄物件，PO-3是商品瀏覽記錄物件，PO-4是添加購物車記錄物件，PO-5是搜索記錄物件，BO是個人網站行為物件，BO物件：{PO-1;PO-2;PO-3;PO-4;PO-5}，這樣做的優點不言而喻，維護代碼的時候查看BO，就能知道這塊邏輯涉及多少表（PO），
易混點三：BO和DTO
搞清楚了BO和PO各自的用途后，我們會發現BO和DTO有重疊功能，一樣可以對PO進行排列組合，那BO的存在的意義是什么呢？
從用途上進行根本的區別，BO是業務物件，DTO是資料傳輸物件，雖然BO也可以排列組合資料，但它的功能是對內的，比如上個例子中的BO物件包括{PO-1;PO-2;PO-3;PO-4;PO-5}還有其他欄位屬性，但在提供對外介面時，BO物件中的某些屬性物件可能用不到或者不方便對外暴露，那么此時DTO只需要在BO的基礎上，抽取自己需要的資料，然后對外提供，
在這個關系上，通常不會有資料內容的變化，內容變化要么在BO內部業務計算的時候完成，要么在解釋VO的時候完成，
DO
DO是領域物件，就是從現實世界中抽象出來的有形或無形的業務物體，事實上，DO和PO在絕大部分情況下是一一對應的，阿里巴巴的開發手冊中的定義DO等同于PO，即與資料庫表結構一一對應，通過DAO層向上傳輸資料源物件，
上一張圖，更加直觀的展示這些名詞使用的節點：
總結
VO，BO，PO，DTO這樣分層還是很有意義的，尤其在團隊成員較多的情況下，結構更加一目了然，同時也能很大程度避免多端系統資料所需不一致時，有人修改屬性影響其他頁面，但也完全沒有必要教條主義，把這些全部用上，需要根據所開發的業務復雜度來取舍，如果本身業務邏輯不負責，照搬全上反而讓開發變的更復雜，
例如業務不復雜，根本沒有多端展示的差異化，VO可以直接拿掉，直接使用DTO傳輸到前端資料即可，
同時在使用程序中，最重要的是要在團隊中達成共識，概念一致，如果使用了這些，但各按各的理解來，甚至抓起來就直接用，反而會讓代碼變得更亂，還不如直接POJO、DTO打天下，
另附這些概念命名規范：
- 資料物件：xxxPO，xxx即為資料表名，(也可DO)
- 資料傳輸物件：xxxDTO，xxx為業務領域相關的名稱，
- 展示物件：xxxVO，xxx一般為網頁名稱，
- 業務物件：xxxBO，xxx是業務名稱，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/380172.html
標籤：Java