為什么使用VO，DTO，BO

一、VO（View Object）

Vo顧名思義是一個有關視圖的對象，主要應用于與前端之間的交互。Vo通常封裝了前端調用某個接口之后，他所需要的所有的數據。Java具有面向對象的特點，但在這個前后端分離的時代，“對象”的定義，不僅僅是一個一個的類，而轉變為一個又一個的接口。對于前端而言，他所面向的對象，便是后端提供的接口，而接口對象怎么去表示呢，我們選擇使用返回對象的含義+Vo去創建實體類，來表示他是一個視圖層的類。

二、DTO（Data Transfer Object）

Dto是相對于web網站中，前后端而言的“數據傳輸層”所需要的對象。Dto主要應用于以下幾處：

在Controller層，接口傳參使用Dto對象來進行接收，無論參數個數多少，就算只有一個參數，也應當創建一個Dto對象進行接收。有人會問，為什么不用@RequestParam來做，簡單來講，一是不美觀，二是維護困難。當參數過多的情況下，接口的一個括號里，會掉滿了各類注解，各類對參數的設定。其次，如果對于接口參數新增或者減少的情況來講，接口參數的維護會很難受。而如果使用Dto傳參，我的維護成本僅僅只是Dto這個對象。無論是新手老手還是誰來接手維護該接口，大家都很明確，我接口是用的Dto來接受的參數，那么我就只需要去研究Dto這個對象有哪一些“屬性”，而這些屬性，又分別具有哪些約束，在對屬性進行約束完畢之后，我接口只需要一個validation，便可進行參數校驗，省去了繁雜的空判斷以及一些特殊屬性的校驗。

在Service層，我們會處理許多復雜的邏輯，但最終的目的，是將處理好的持久化。如果將持久層的東西拿出來進行各類復雜的處理之后，就算是老程序員，也很容易將需要持久化的對象，進行錯誤返回，所以使用Dto對象，只需要把處理完的Dto進行copyBean即可無傷轉換為持久化對象（Bo）。

三、Po（Persistent Object）

Po設計的意義就是讓對象只做一件事，是用于Java后端與數據庫之間進行交互，Po的命名不限制于XxxxPo，而應當與數據庫表和字段所對應。與前端的交互只管交給Vo去做，數據處理層的交互只管交給Dto去做，與數據庫的交互只管交給Po去做。MVC架構，每層的對象分工明確。

有人說Java是一門面向對象的語言，重要的就是“對象”，而使用Vo，Dto，Po的人，反而是丟棄了面向對象的一面大旗，因為他們搞不懂自己面向的對象到底是什么，所以一概成為Vo，Dto，Po。我想說，并不是這樣。Vo的命名規則，應當是前端獲取的資源+Vo構成。Dto的命名規則，應當是接口名稱+Dto構成。而Po的命名規則，應當與數據庫相對應。對于接口Vo而言不僅明確接口返回的對象是何種資源，而且滿足Restful風格的Url（url表現出獲取的資源是什么）。對于Dto而言，它就是專注于該接口的一個接受參數的對象。

對于這種對象的使用方式，管理起來也很簡單，只需根據接口，就能夠迅速的定位到自己想要的對象是什么，如果前端需要的字段多一條，那我只需要在Vo對象中加一個屬性，在業務層處理好數據，set到Vo里面去。如果我在業務層的判斷需要新的字段，那我只需要定位到對應的Dto對象中，添加需要的屬性。如果不使用Vo，Dto，Po進行區分，我一個剛接手的新手程序員，我應該如何去判斷這個對象是個什么對象呢？它是數據庫對象嗎？還是返回給前端展示的對象？還是說從持久層開始到視圖層，我一直都使用的是同一個對象？這樣的使用方式真的合適嗎？如果前端所需要的新的字段，那我應當修改返回的“持久層對象”？這應當修改嗎？顯然不合理。

在Springboot+vue前后端分離盛行的時代，這種對象的使用和管理方式，我認為是非常值得推薦的。

總結

以上是生活随笔為你收集整理的为什么使用VO，DTO，BO的全部內容，希望文章能夠幫你解決所遇到的問題。

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