最近，有小伙伴反饋：很困惑代碼里用什么對象來傳輸數(shù)據(jù)，是共用一個對象還是每層各用一個對象，對于數(shù)據(jù)對象又該如何命名，種種困惑導(dǎo)致代碼結(jié)構(gòu)很混亂。針對該問題，今天就一起來聊聊這個看似簡單，其實很多人都在誤用的代碼分層以及對象命名問題。

說起代碼分層，那就不得不提起 MVC模式，相信很多程序員的編程啟蒙階段都有它的陪伴。

1. 什么是MVC？

MVC是后端業(yè)務(wù)開發(fā)最常見，使用頻率最高的一種編程模式，因此，本文將結(jié)合 Java語言對 MVC做簡要的介紹：

M：Mode，數(shù)據(jù)層，負責(zé)和數(shù)據(jù)庫交互；

V：View，視圖層，負責(zé)顯示數(shù)據(jù)給用戶，并向用戶呈現(xiàn)信息；

C：Controller，邏輯層，負責(zé)處理用戶的輸入和相應(yīng)操作；

早期，在 Java語言中，JSP（Java Server Page） 是 View視圖的最好體現(xiàn)，有過 JSP經(jīng)歷的開發(fā)人員一定深深體會到了它的辛酸，隨著互聯(lián)網(wǎng)的快速發(fā)展，這種前端頁面在后端代碼中去編寫顯然滿足不了市場的需求，隨之而來的是前后端分離，基于前后端分離的場景，MVC模式與 Java常見的代碼分層的對應(yīng)關(guān)系可以如下圖所示：

上圖 Controller-Service-Repository 三層架構(gòu)模型是前后端分離場景下 MVC最經(jīng)典體現(xiàn)，目前，絕大多數(shù)的公司都是直接或者間接使用這個模型。盡管不同公司，代碼架構(gòu)略有差異，但萬變不離窮，掌握了MVC三層架構(gòu)就能輕松的去使用其他模型。

2. 公共對象貫穿MVC

講完了 MVC模型，接下來的問題是：Controller-Service-Repository 各層之間通過什么對象傳輸數(shù)據(jù)呢？

你是否寫過這樣的代碼？一個公共的對象，貫穿整個MVC，如下圖， User對象從Controller層接收用戶參數(shù)，一直到Repository 層，最終存儲到 DB中。

上圖是很多中初級程序員最容易出現(xiàn)的代碼，一個類對象將參數(shù)從最頂層傳到最底層，然后又將最底層的 DB數(shù)據(jù)輸出到最頂層，簡單粗暴，這樣會產(chǎn)生什么問題呢？

• 安全性：用戶的入?yún)⒖梢灾眰鞯紻B，存在SQL注入到風(fēng)險，DB出來的數(shù)據(jù)直接到達View層，這樣某些敏感數(shù)據(jù)可能會泄漏，比如注冊功能，可能把密碼暴露。
• 使用困惱：對于接收入?yún)⒌膶ο?，一般是需要什么?shù)據(jù)，定義什么參數(shù)，假如把一個大而全的對象直接暴露給用戶，這樣對接的用戶對于入?yún)髦稻蜁芾Щ蟆?/li>
• 耦合性：如果各層都依賴于相同的數(shù)據(jù)對象，更改一個層次的數(shù)據(jù)結(jié)構(gòu)可能會影響其他層次，系統(tǒng)耦合性太強。

這里只列舉了 3個比較常見的問題，那么有什么好的方式可以解決這個問題呢？

最常用的方法是：使用VO，BO，DO對各層進行數(shù)據(jù)傳輸。

3. VO，BO，DO

VO：View Object，視圖對象，用于 Controller層的數(shù)據(jù)對象；

BO：Business Object，業(yè)務(wù)對象，用于 Service層的數(shù)據(jù)對象；

DO：Domain Object，數(shù)據(jù)對象，用于 Repository層的數(shù)據(jù)對象，也可以叫做 Entity；

VO，BO，DO本質(zhì)上是對數(shù)據(jù)類對象起一個規(guī)范的名字，比如：UserVO，UserBO，UserDO，它就和 xxxController，xxxService，xxxRepository 一樣，見名知意，讓人看見名字就知道它的職責(zé)。

為了更好的說明 VO，BO，DO，我們以一個生活中的實例“領(lǐng)導(dǎo)配秘書“來進行講解。如下圖：

當各層共用一個數(shù)據(jù)對象時，類比 董事長，CEO，總經(jīng)理共用一個秘書，我們一起來分析上面提到的 3個常見問題：

• 安全性：共用秘書，董事長的秘密會不會暴露給CEO和總經(jīng)理呢？安全嗎？
• 耦合性：一個秘書要干 3個人的事情，每個領(lǐng)導(dǎo)的事情不一樣，怎么解耦？
• 使用困惑：當員工要反映問題時，秘書該反映到哪一層領(lǐng)導(dǎo)呢？

因此，聞道有先后，術(shù)業(yè)有專攻，專業(yè)的事就得干專業(yè)的人來干。董事長，CEO，總經(jīng)理共用一個秘書顯然不合理，必須配備自己的專職秘書；同理，Controller層，Service層，Repository層共用一個數(shù)據(jù)類對象也是不合理的，必須配備特定的類對象，對比圖如下：

通過上圖中每層領(lǐng)導(dǎo)配備專職秘書的實例，是不是能很好的理解 VO，BO，DO的作用：各層對象只負責(zé)自己本層的數(shù)據(jù)，劃清邊界，清晰職責(zé)。

因此，MVC，代碼分層以及各層數(shù)據(jù)對象的對應(yīng)關(guān)系可以描述成下圖：

需要注意：因為 VO，BO，DO 需要定義屬性來傳遞數(shù)據(jù)，因此難免會帶來一個問題：三者出現(xiàn)重復(fù)的代碼。這個問題合理嗎？需要如何處理呢？

4. 消除重復(fù)代碼

首先我們來分析三者出現(xiàn)重復(fù)的代碼是否合理？

比如，用戶注冊功能，我們會在 UserVO，UserBO，UserDO中都定義相同的字段 username， password，如下圖：

盡管三個類中都包含了相同的字段和getter和setter方法，但是因為他們的語義不一樣，職責(zé)也不一樣，所以這種重復(fù)是合理的。

有沒有好的辦法來消除這種重復(fù)呢？

有，將相同的屬性抽到公共的類中，通過繼承獲得，如下圖：

上圖，我們抽取了一個父類 BaseUser來存放共用的字段，這樣就可以達到代碼復(fù)用，然后在每個子類對象中去定義特定的屬性。既然類對象之間需要傳輸數(shù)據(jù)，那么該如何相互轉(zhuǎn)換呢？

5. 對象相互轉(zhuǎn)換

在實際開發(fā)中，我們一般會定義 Converter 類來負責(zé)對象之間的拷貝，如下圖：

方法一：手動set

該方式缺點：需要手動編寫 set方法，代碼量比較多；優(yōu)點：一個類對象更換了字段名，賦值會報錯，能及時發(fā)現(xiàn)。

方法二：使用Apache的BeanUtils等工具進行拷貝

該方式優(yōu)點：使用三方類包裝的方式，簡單易用；缺點：像BeanUtils工具，只會拷貝相同的屬性，當一個類對象換了字段名，不會報錯，不能及時發(fā)現(xiàn)。

兩種方式各有優(yōu)缺點，實際開發(fā)中都會用到，具體選擇哪一種需要技術(shù)團隊內(nèi)部討論決定。

6. 總結(jié)

• 本文講解了 MVC模式以及Java與之對應(yīng)的代碼分層；
• 本文講解了在代碼各層共用一個類對象傳輸數(shù)據(jù)的優(yōu)缺點，并且結(jié)合現(xiàn)實生活中領(lǐng)導(dǎo)配秘書來類比講解；
• 本文講解VO，BO，DO 的作用以及如何使用，分析了如何消除三者之間重復(fù)的代碼，同樣結(jié)合現(xiàn)實生活中領(lǐng)導(dǎo)配秘書來類比講解；
• MVC 是代碼分層的精髓，盡管很多公司不一定嚴格遵守MVC，但是萬變不離其宗，掌握了精髓，才能輕松玩轉(zhuǎn)其他的分層風(fēng)格；

到此這篇關(guān)于Java中的 VO，BO，DO 對象命名問題的文章就介紹到這了,更多相關(guān)Java VO 對象命名內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論