今天給大家帶來一篇關于VO，BO，PO，DO，DTO的文章，閱讀完這篇文章之后，希望大家對VO，BO，PO，DO，DTO有自己的見解。

VO，BO，PO，DO，DTO

概念

在講具體的概念之前，我們先簡單的講一講我們MVC開發模式。

MVC的簡單定義：

M層負責與數據庫打交道；

C層負責業務邏輯的編寫；

V層負責給用戶展示（針對于前后端不分離的項目，不分離項目那種編寫模版的方式，理解V的概念更直觀）。

而我們今天要說的VO，BO，PO，DO，DTO呢，就是穿梭在這M、V、C層之間的實體傳輸對象。

實體傳輸對象示意圖

• VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數據封裝起來。
• DTO（Data Transfer Object）：數據傳輸對象，這個概念來源于J2EE的設計模式，原來的目的是為了EJB的分布式應用提供粗粒度的數據實體，以減少分布式調用的次數，從而提高分布式調用的性能和降低網絡負載，但在這里，更符合泛指用于展示層與服務層之間的數據傳輸對象。
• BO（Business Object）：業務對象，把業務邏輯封裝為一個對象，這個對象可以包括一個或多個其它的對象。
• PO（Persistent Object）：持久化對象，它跟持久層（通常是關系型數據庫）的數據結構形成一一對應的映射關系，如果持久層是關系型數據庫，那么，數據表中的每個字段（或若干個）就對應PO的一個（或若干個）屬性。
• DO（Domain Object）：領域對象，就是從現實世界中抽象出來的有形或無形的業務實體。

有必要用嗎？

項目中真的有必要定義VO，BO，PO，DO，DTO嗎？

還是要理性看待這個問題，要看我們項目“目的地”是什么。

如果項目比較小，是一個簡單的MVC項目，又是單兵作戰，我不建議使用VO，BO，PO，DO，DTO，直接用POJO負責各個層來傳輸就好，因為這種項目的“目的地”是快速完成。

而我們更多的時候，是持續迭代的團隊協作項目，這個時候我們就建議用VO，BO，PO，DO，DTO，而且團隊內要達成共識，形成一個標準規范。

業務復雜，人員協同性要求高的場景下，這些規范性的東西不按著來雖然不會出錯，程序照樣跑，但是遵守規范會讓程序更具擴展性和可讀性；

讓類語義更明確，很容易知道類的含義；

其實就是提升項目的可擴展性、可維護性與可閱讀性。

提升這些性能的盡頭是經濟效益。

總結

這篇文章很短，最后稍微總結一下，不管用哪種方式，只要團隊內定義好一種適應的協同規范就行。

沒有一個絕對好與絕對壞的方式方法。

團隊規范的盡頭能提升項目的可擴展性、可維護性與可閱讀性，從而降低bug率。

另附這些概念命名規范：

• 數據對象：xxxPO，xxx即為數據表名。(也可DO)
• 數據傳輸對象：xxxDTO，xxx為業務領域相關的名稱。
• 展示對象：xxxVO，xxx一般為網頁名稱。
• 業務對象：xxxBO，xxx是業務名稱。

總結

以上是生活随笔為你收集整理的真的有必要定义VO，BO，PO，DO，DTO吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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