前言
相信很多人都有類似的經(jīng)歷：隨著業(yè)務(wù)越來(lái)越多， 系統(tǒng)的越來(lái)越復(fù)雜， 我們都會(huì)感覺(jué)我們的代碼越來(lái)越難看， 重復(fù)代碼越來(lái)越多， 越來(lái)越難以維護(hù)。 恩， 這確實(shí)是個(gè)問(wèn)題， 但有沒(méi)有可能解決的辦法？ 老實(shí)說(shuō)， 確實(shí)很難， 但不是完全沒(méi)有可能， 或者說(shuō)有改善的可能。 最近就關(guān)于這方面進(jìn)行了一些學(xué)習(xí)和考慮， 以純理論的方式總結(jié)了一下， 希望能對(duì)對(duì)這方面有興趣的同學(xué)有所幫助。

很多面向應(yīng)用的系統(tǒng)是以數(shù)據(jù)為中心的， 在這些系統(tǒng)中， 以數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)； 業(yè)務(wù)邏輯代碼則根據(jù)需求圍繞著數(shù)據(jù)庫(kù)中存儲(chǔ)的數(shù)據(jù)來(lái)組織邏輯；以購(gòu)買商品的系統(tǒng)為例， 商品數(shù)據(jù)， 交易數(shù)據(jù)和用戶數(shù)據(jù)是系統(tǒng)中的核心數(shù)據(jù)， 絕大多數(shù)業(yè)務(wù)代碼則是根據(jù)需求來(lái)倒騰這些數(shù)據(jù)。這個(gè)非常符合那個(gè)關(guān)于程序的定義： 程序 = 數(shù)據(jù) + 行為； 在這里， 數(shù)據(jù)是數(shù)據(jù)庫(kù)中的數(shù)據(jù)， 行為則對(duì)應(yīng)業(yè)務(wù)邏輯。

對(duì)于所構(gòu)建的系統(tǒng)， 我們自然希望可擴(kuò)展性好， 可維護(hù)性；這是一個(gè)非常有挑戰(zhàn)性對(duì)的事情， 大型的應(yīng)用尤其如此； 能否真的做就在很大程度取決于邏輯的組織方式。 這篇文章大體介紹以數(shù)據(jù)庫(kù)為中心的應(yīng)用中的三個(gè)典型的業(yè)務(wù)邏輯組織方式。

邏輯組織方式
事務(wù)腳本方式
這里的事務(wù)與數(shù)據(jù)庫(kù)術(shù)語(yǔ)事務(wù)有所區(qū)別， 這里的事務(wù)更多的指一次業(yè)務(wù)交互。

在應(yīng)用系統(tǒng)中， 大多數(shù)業(yè)務(wù)邏輯可以看做一系列子任務(wù)的集合； 比如用戶購(gòu)買一個(gè)商品時(shí)， 可以大體分成幾步：

先根據(jù)商品的信息到數(shù)據(jù)庫(kù)中查詢是否有可銷售的商品存在；有的話， 添加一個(gè)用戶購(gòu)買商品的購(gòu)買記錄；然后把商品數(shù)量減少；其他事情， 比如發(fā)郵件通知用戶等。

以事務(wù)腳本方式組織代碼時(shí)， 業(yè)務(wù)邏輯組織上沒(méi)有層次之分， 在實(shí)現(xiàn)一個(gè)具體業(yè)務(wù)時(shí)， 根據(jù)其業(yè)務(wù)的需要從前到后進(jìn)行一系列的事務(wù)調(diào)用； 就購(gòu)買商品為例， 先從數(shù)據(jù)庫(kù)中查詢商品數(shù)量， 然后判斷是否足夠， 足夠的話添加用戶購(gòu)買商品的記錄， 然后操作數(shù)據(jù)庫(kù)減少商品。這種方式有個(gè)明顯的特點(diǎn)， 一個(gè)事務(wù)腳本實(shí)現(xiàn)以一個(gè)用例或者或者一個(gè)功能。這個(gè)方式優(yōu)點(diǎn)很明顯， 簡(jiǎn)單，直觀， 易學(xué)易用，開發(fā)速度快；這些容易理解， 因?yàn)檫@些寫代碼的方式與直觀的思維方式類似， 在實(shí)際中， 很多系統(tǒng)都是這樣實(shí)現(xiàn)的；尤其那些快速開發(fā)系統(tǒng)； 但是抽象度低， 容易導(dǎo)致重復(fù)代碼多，與其他系統(tǒng)的耦合程度高， 維護(hù)麻煩，尤其是對(duì)于復(fù)雜的系統(tǒng)來(lái)說(shuō)。 舉個(gè)例子來(lái)說(shuō)，購(gòu)買商品購(gòu)買這個(gè)功能，桌面版提供了之后，手機(jī)版的也需要實(shí)現(xiàn)， 由于手機(jī)版與桌面版是兩個(gè)不同的用例， 如果用事務(wù)腳本來(lái)組織代碼的話， 很自然的就會(huì)出現(xiàn)類似的代碼出現(xiàn)在了不同的地方的情況。 一個(gè)很明顯的優(yōu)化是封裝成函數(shù)， 但是封裝成函數(shù)這個(gè)事情的模塊化程度低， 在業(yè)務(wù)復(fù)雜的情況下， 對(duì)業(yè)務(wù)邏輯的有效管理和維護(hù)是一個(gè)挑戰(zhàn)。

事務(wù)腳本這種方式適用于相對(duì)簡(jiǎn)單的業(yè)務(wù)邏輯環(huán)境，而且在現(xiàn)實(shí)中， 很多業(yè)務(wù)本身就是簡(jiǎn)單的， 這種方式可以在開發(fā)高效， 運(yùn)行高效的前提下工作的很好； 另外對(duì)于快速開發(fā)環(huán)境中也非常適用。 但是當(dāng)業(yè)務(wù)邏輯復(fù)雜， 而且上線后維護(hù)期很長(zhǎng)或維護(hù)量很大的系統(tǒng)來(lái)說(shuō)，可能不是一種很好的方式。

表模塊方式
在事務(wù)腳本方式當(dāng)中，很容易導(dǎo)致:相同或者類似的代碼重復(fù)出現(xiàn);相關(guān)邏輯分布在多個(gè)地方。

對(duì)于前一個(gè)問(wèn)題， 可以通過(guò)把相同或者相似邏輯封裝成函數(shù)來(lái)改進(jìn)， 第二個(gè)問(wèn)題通過(guò)流程或規(guī)范可以得到控制。 但是， 還是會(huì)在業(yè)務(wù)復(fù)雜的情況下對(duì)業(yè)務(wù)邏輯的有效管理和維護(hù)是一個(gè)挑戰(zhàn) 因?yàn)槿狈σ环N有效的編碼的機(jī)制來(lái)控制這樣的問(wèn)題。
表模塊組織方可以從機(jī)制上提供一個(gè)相對(duì)好的解決辦法， 其大概思路是，把與一個(gè)或者多個(gè)數(shù)據(jù)庫(kù)表(或者視圖)有關(guān)的邏輯組織成一個(gè)類， 把對(duì)與這個(gè)表有關(guān)的邏輯組織成這個(gè)類的方法。以上面那個(gè)購(gòu)買商品為例， 查詢商品是否足夠可能是一個(gè)單獨(dú)的方法， 修改商品數(shù)量是一個(gè)單獨(dú)的方法；購(gòu)買商品是一個(gè)方法，所完成的事情就是把前面兩個(gè)方法組織起來(lái)。 一旦有了這個(gè)邏輯， 只要是需要用到購(gòu)買商品邏輯的地方， 直接調(diào)用這個(gè)購(gòu)買商品的方法就可以了； 除了這個(gè)購(gòu)買商品之外， 其他與商品有關(guān)邏輯都組織在這個(gè)類里面，避免了與商品有關(guān)的邏輯分布到多個(gè)地方。

除了提供一個(gè)代碼組織的方式外，這種組織方式還有一些其他的好處：不需要數(shù)據(jù)庫(kù)表就直接可以測(cè)試，也便于打樁測(cè)試； 與很多數(shù)語(yǔ)言提供的數(shù)據(jù)庫(kù)操作API配合使用方便， 很多數(shù)據(jù)庫(kù)操作API返回的結(jié)果都市記錄集的方式， 尤其以微軟提供的相關(guān)API為典型代表， .NET提供的Dataset更是功能強(qiáng)大。實(shí)際上， 微軟提供的開發(fā)平臺(tái)倡導(dǎo)的就是以表模塊方式組織邏輯， 并提供了各種便利的開發(fā)工具和API； 在管理代碼的有效性和復(fù)雜度上有比較好的平衡，他比前面的事務(wù)腳本方式相對(duì)繁瑣點(diǎn)， 比后面好提到的領(lǐng)域模型方式簡(jiǎn)單很多。

領(lǐng)域模型

領(lǐng)域模型方式組織代碼就是OO的編程思想， 把領(lǐng)域邏輯對(duì)象化， 從而達(dá)到在復(fù)雜的業(yè)務(wù)邏輯是有好的可擴(kuò)展性和可維護(hù)性。表模塊組織方式在管理代碼的有效性和復(fù)雜度上有比較好的平衡， 但是在其提供的抽象機(jī)制畢竟有限； 在管理復(fù)雜的業(yè)務(wù)邏輯方面有些不給力。比如， 對(duì)于不同類型的商品， 其購(gòu)買邏輯可能不一樣；這時(shí)候， 面向?qū)幋a的威力會(huì)就能比較好的發(fā)揮了， 商品這個(gè)例子中， 購(gòu)買時(shí)的行為可能不一樣， 利用多態(tài)機(jī)制， 對(duì)調(diào)用者來(lái)說(shuō)可能是透明的。

領(lǐng)域模型這種方式與表模型的方式的區(qū)別在于OO的力度不一樣； 表模型以表為單位來(lái)組織， 領(lǐng)域模型可能則以表里面的記錄為單位來(lái)組織的， 因此代碼中， 一個(gè)表只有一個(gè)類實(shí)例， 而領(lǐng)域模型則會(huì)針對(duì)一條記錄有個(gè)對(duì)象。

模型這種方式的優(yōu)點(diǎn)是便于有效的管理復(fù)雜性和可擴(kuò)展性， 對(duì)于復(fù)雜的業(yè)務(wù)邏輯以及那種維護(hù)周期很長(zhǎng)的系統(tǒng)來(lái)說(shuō)比較適用； 但其缺點(diǎn)也很明： OO建模復(fù)雜，開發(fā)周期相對(duì)會(huì)長(zhǎng)些；學(xué)習(xí)成本高， 尤其對(duì)于新團(tuán)隊(duì)來(lái)說(shuō)； 同樣， 如果代碼組織不好， 也會(huì)出現(xiàn)其他方式中出現(xiàn)的類似問(wèn)題， 如代碼重復(fù)等。

小結(jié)
三種不同的邏輯組織方式各有特點(diǎn)， 適用于不同的場(chǎng)合， 可以根據(jù)實(shí)際情況選擇， 一般來(lái)說(shuō)， 簡(jiǎn)單應(yīng)用， 要求快速開發(fā)快， 維護(hù)周期短的可以考慮事務(wù)腳本方式； 業(yè)務(wù)邏輯復(fù)雜， 維護(hù)周期長(zhǎng)時(shí)， 在開發(fā)人員技能滿足的條件下可以考慮領(lǐng)域模型； 在這個(gè)兩個(gè)中間的情況可以考慮表模塊方式， 尤其是在微軟的平臺(tái)上。 在實(shí)際中，由于實(shí)際業(yè)務(wù)的復(fù)雜性， 很多時(shí)候以一種單一的方式組織還不夠， 可能幾個(gè)方式綜合起來(lái)運(yùn)用。 比如， 把核心業(yè)務(wù)按領(lǐng)域?qū)ο蟮姆绞浇M織， 之上再以事務(wù)腳本來(lái)組織多變的應(yīng)用業(yè)務(wù)。

it知識(shí)庫(kù)：以數(shù)據(jù)庫(kù)為中心的系統(tǒng)中的業(yè)務(wù)邏輯組織方式，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。