一、概念

• VO (View Object)，用于表示一個與前端進行交互的視圖對象，它的作用是把某個指定頁面(或組件)的所有數據封裝起來。實際上，這里的 VO 只包含前端需要展示的數據，對于前端不需要的數據，比如數據創建和修改的時間等字段，出于減少傳輸數據量大小和保護數據庫結構不外泄的目的，不應該在 VO 中體現出來。

• DTO(Data Transfer Object)，用于表示一個數據傳輸對象，DTO 通常用于展示層(Controller)和服務層(Service)之間的數據傳輸對象。DTO 與 VO 概念相似，并且通常情況下字段也基本一致。但 DTO 與 VO 又有一些不同，這個不同主要是設計理念上的，比如 API 服務需要使用的 DTO 就可能與 VO 存在差異。

• DO(Data Object) ，持久化對象，它跟持久層(Dao)的數據結構形成一一對應的映射關系。如果持久層是關系型數據庫，那么數據庫表中的每個字段就對應PO的一個屬性，常是entity實體類。

• BO（Business Object）：業務對象，就是從現實世界中抽象出來的有形或無形的業務實體。

阿里Java開發手冊分層領域模型：

二、為什么會存在Vo？

項目中，看到別人直接把DTO，寫上swagger注釋，直接返回前端。那么思考一下，為什么不建議這么做，不直接把DTO返回給前端。

• 從開發過程講，前后端首先會以vo和param作為返回、傳參的協議的定義，再定義協議之前，都沒有實際的業務邏輯的處理，也就不會存在dto。

• 從項目的整體考慮，如果把dto作為傳給前端的對象，那么service層返回dto，service層的所有的方法不一定都是public方法，也有private方法，如果private方法也返回dto，那么也就是說有些dto不是提供給前端的，有些是給前端的，這樣就會亂，沒有了隔離性。

• 從字段的修改來說，service層的方法是可以共用的，一個service方法返回的dto，可能會被很多個controlller方法使用到，即使目前不會，將來也可能會，dto會有很多參數，比如包含了主表信息，子表信息，而傳給前端的vo只有dto的一部分信息，而且不同請求給前端看到的數據不一樣，所以dto是共用的，vo是個性化的，如果直接把dto提供給前端，將會導致耦合性非常大，一旦一個接口的需求變了，修改了dto，增加了一個字段，將會導致接口直接把這個新增的字段返回給了前端，導致（接口輸出數據多余，和不安全性）。同理，如果由于某個需求，把dto展示給前端的接口說要刪除某一個字段，那么因為這個dto被很多接口引用，一刪除就會導致出問題。

所以，總整體性結構而言：vo是必須存在的，不能把dto直接返回給前端。高內聚，低耦合。

三、其他問題

1. VO可以復用嗎？

比如，一個接口需要VO，另一個接口需要VO加上別的一些數據，這種情況，是繼承VO使用，還是再寫一個VO？

答案：VO最好不要復用。VO目的就是解耦，應該是并列關系的，如果存在復用，那么就可能導致，一方修改影響另一方。一旦存在繼承關系，繼承來繼承去，最后關系就會變得很亂，不好維護。

2. Controller層接收的參數是VO還是DTO？

希望大家根據公司情況來定，我們公司前端交互是統一VO的。

Controller層接收的應該是VO，但是根據情況而定，尤其是前后分離，有特定的前端開發人員時，因為DTO往往會添加很多額外的數據信息，打個比方，用戶新增，往往前端傳遞的是賬戶名、密碼、創建人標識等等很少的信息，但是DTO作為一個中轉數據，會添加例如更新人、用戶狀態等等其他的信息，如果前端傳遞的是DTO，如此多的額外信息會給前端造成很多問題。如果是小項目的話，前后端都是一個人在進行，那就無所謂了，后端需要哪些，不需要哪些心里有數，傳遞DTO就無所謂了。

一般的數據傳遞是，前端傳遞VO給接口(Controller)，接口將VO轉為DTO傳遞給service，service將DTO分解為DO，調用領域服務進行調度，然后逆向轉為VO或者其他的返回結果，傳遞給前臺。

總結

以上是生活随笔為你收集整理的浅析VO、DTO、DO、BO的概念、区别和用处的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。