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

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

1. 什么是MVC？

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

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

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

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

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

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

2. 公共對(duì)象貫穿MVC

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

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

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

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

這里只列舉了 3個(gè)比較常見(jiàn)的問(wèn)題，那么有什么好的方式可以解決這個(gè)問(wèn)題呢？

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

3. VO，BO，DO

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

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

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

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

為了更好的說(shuō)明 VO，BO，DO，我們以一個(gè)生活中的實(shí)例“領(lǐng)導(dǎo)配秘書(shū)“來(lái)進(jìn)行講解。如下圖：

當(dāng)各層共用一個(gè)數(shù)據(jù)對(duì)象時(shí)，類(lèi)比 董事長(zhǎng)，CEO，總經(jīng)理共用一個(gè)秘書(shū)，我們一起來(lái)分析上面提到的 3個(gè)常見(jiàn)問(wèn)題：

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

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

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

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

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

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

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

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

盡管三個(gè)類(lèi)中都包含了相同的字段和getter和setter方法，但是因?yàn)樗麄兊恼Z(yǔ)義不一樣，職責(zé)也不一樣，所以這種重復(fù)是合理的。

有沒(méi)有好的辦法來(lái)消除這種重復(fù)呢？

有，將相同的屬性抽到公共的類(lèi)中，通過(guò)繼承獲得，如下圖：

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

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

在實(shí)際開(kāi)發(fā)中，我們一般會(huì)定義 Converter 類(lèi)來(lái)負(fù)責(zé)對(duì)象之間的拷貝，如下圖：

方法一：手動(dòng)set

該方式缺點(diǎn)：需要手動(dòng)編寫(xiě) set方法，代碼量比較多；優(yōu)點(diǎn)：一個(gè)類(lèi)對(duì)象更換了字段名，賦值會(huì)報(bào)錯(cuò)，能及時(shí)發(fā)現(xiàn)。

方法二：使用Apache的BeanUtils等工具進(jìn)行拷貝

該方式優(yōu)點(diǎn)：使用三方類(lèi)包裝的方式，簡(jiǎn)單易用；缺點(diǎn)：像BeanUtils工具，只會(huì)拷貝相同的屬性，當(dāng)一個(gè)類(lèi)對(duì)象換了字段名，不會(huì)報(bào)錯(cuò)，不能及時(shí)發(fā)現(xiàn)。

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

6. 總結(jié)

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

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

最新評(píng)論