真的有必要定義VO，BO，PO，DO，DTO嗎？
發(fā)布日期：2022/6/27 12:14:19 瀏覽量：
今天給大家?guī)硪黄P(guān)于VO，BO，PO，DO，DTO的文章，閱讀完這篇文章之后，希望大家對VO，BO，PO，DO，DTO有自己的見解。
VO，BO，PO，DO，DTO
概念
在講具體的概念之前，我們先簡單的講一講我們MVC開發(fā)模式。
MVC的簡單定義：
M層負責(zé)與數(shù)據(jù)庫打交道；
C層負責(zé)業(yè)務(wù)邏輯的編寫；
V層負責(zé)給用戶展示（針對于前后端不分離的項目，不分離項目那種編寫模版的方式，理解V的概念更直觀）。
而我們今天要說的VO，BO，PO，DO，DTO呢，就是穿梭在這M、V、C層之間的實體傳輸對象。
實體傳輸對象示意圖
- VO（View Object）：視圖對象，用于展示層，它的作用是把某個指定頁面（或組件）的所有數(shù)據(jù)封裝起來。
- DTO（Data Transfer Object）：數(shù)據(jù)傳輸對象，這個概念來源于J2EE的設(shè)計模式，原來的目的是為了EJB的分布式應(yīng)用提供粗粒度的數(shù)據(jù)實體，以減少分布式調(diào)用的次數(shù)，從而提高分布式調(diào)用的性能和降低網(wǎng)絡(luò)負載，但在這里，更符合泛指用于展示層與服務(wù)層之間的數(shù)據(jù)傳輸對象。
- BO（Business Object）：業(yè)務(wù)對象，把業(yè)務(wù)邏輯封裝為一個對象，這個對象可以包括一個或多個其它的對象。
- PO（Persistent Object）：持久化對象，它跟持久層（通常是關(guān)系型數(shù)據(jù)庫）的數(shù)據(jù)結(jié)構(gòu)形成一一對應(yīng)的映射關(guān)系，如果持久層是關(guān)系型數(shù)據(jù)庫，那么，數(shù)據(jù)表中的每個字段（或若干個）就對應(yīng)PO的一個（或若干個）屬性。
- DO（Domain Object）：領(lǐng)域?qū)ο?/strong>，就是從現(xiàn)實世界中抽象出來的有形或無形的業(yè)務(wù)實體。
項目中真的有必要定義VO，BO，PO，DO，DTO嗎？
還是要理性看待這個問題，要看我們項目“目的地”是什么。
如果項目比較小，是一個簡單的MVC項目，又是單兵作戰(zhàn)，我不建議使用VO，BO，PO，DO，DTO，直接用POJO負責(zé)各個層來傳輸就好，因為這種項目的“目的地”是快速完成。
而我們更多的時候，是持續(xù)迭代的團隊協(xié)作項目，這個時候我們就建議用VO，BO，PO，DO，DTO，而且團隊內(nèi)要達成共識，形成一個標準規(guī)范。
- 業(yè)務(wù)復(fù)雜，人員協(xié)同性要求高的場景下，這些規(guī)范性的東西不按著來雖然不會出錯，程序照樣跑，但是遵守規(guī)范會讓程序更具擴展性和可讀性；
- 讓類語義更明確，很容易知道類的含義；
其實就是提升項目的可擴展性、可維護性與可閱讀性。
提升這些性能的盡頭是經(jīng)濟效益。
總結(jié)
這篇文章很短，最后稍微總結(jié)一下，不管用哪種方式，只要團隊內(nèi)定義好一種適應(yīng)的協(xié)同規(guī)范就行。
沒有一個絕對好與絕對壞的方式方法。
團隊規(guī)范的盡頭能提升項目的可擴展性、可維護性與可閱讀性，從而降低bug率。
另附這些概念命名規(guī)范：
- 數(shù)據(jù)對象：xxxPO，xxx即為數(shù)據(jù)表名。(也可DO)
- 數(shù)據(jù)傳輸對象：xxxDTO，xxx為業(yè)務(wù)領(lǐng)域相關(guān)的名稱。
- 展示對象：xxxVO，xxx一般為網(wǎng)頁名稱。
- 業(yè)務(wù)對象：xxxBO，xxx是業(yè)務(wù)名稱。
業(yè)務(wù)實施流程 馬上咨詢： 如果您有業(yè)務(wù)方面的問題或者需求，歡迎您咨詢！我們帶來的不僅僅是技術(shù)，還有行業(yè)經(jīng)驗積累。
QQ: 39764417/308460098 Phone: 13 9800 1 9844 / 135 6887 9550 聯(lián)系人：石先生/雷先生