以資料庫為中心的系統中的商務邏輯組織方式

 

作者：百度有啊實驗室
來源：http://www.youalab.com/?p=458

前言

相信很多人都有類似的經曆：隨著業務越來越多， 系統的越來越複雜， 我們都會感覺我們的代碼越來越難看， 重複代碼越來越多， 越來越難以維護。 恩， 這確實是個問題， 但有沒有可能解決的辦法？ 老實說， 確實很難， 但不是完全沒有可能， 或者說有改善的可能。 最近就關於這方面進行了一些學習和考慮， 以純理論的方式總結了一下， 希望能對對這方面有興趣的同學有所協助。

很多面嚮應用的系統是以資料為中心的， 在這些系統中， 以資料庫儲存資料； 商務邏輯代碼則根據需求圍繞著資料庫中儲存的資料來組織邏輯；以購買商品的系統為例， 商品資料， 交易資料和使用者資料是系統中的核心資料， 絕大多數業務代碼則是根據需求來倒騰這些資料。這個非常符合那個關於程式的定義： 程式 = 資料 + 行為； 在這裡， 資料是資料庫中的資料， 行為則對應商務邏輯。

對於所構建的系統， 我們自然希望可擴充性好， 可維護性；這是一個非常有挑戰性對的事情， 大型的應用尤其如此； 能否真的做就在很大程度取決於邏輯的組織方式。 這篇文章大體介紹以資料庫為中心的應用中的三個典型的商務邏輯組織方式。

邏輯組織方式事務指令碼方式

這裡的事務與資料庫術語事務有所區別， 這裡的事務更多的指一次業務互動。

在應用系統中， 大多數商務邏輯可以看做一系列子任務的集合； 比如使用者購買一個商品時， 可以大體分成幾步：

1. 先根據商品的資訊到資料庫中查詢是否有可銷售的商品存在；
2. 有的話， 添加一個使用者購買商品的購買記錄；
3. 然後把商品數量減少；
4. 其他事情， 比如發郵件通知使用者等。

以事務指令碼方式組織代碼時， 商務邏輯組織上沒有層次之分， 在實現一個具體業務時， 根據其業務的需要從前到後進行一系列的事務調用； 就購買商品為例， 先從資料庫中查詢商品數量， 然後判斷是否足夠， 足夠的話添加使用者購買商品的記錄， 然後操作資料庫減少商品。這種方式有個明顯的特點， 一個事務指令碼實現以一個用例或者或者一個功能。這個方式優點很明顯， 簡單，直觀， 易學易用，開發速度快；這些容易理解， 因為這些寫代碼的方式與直觀的思維方式類似， 在實際中， 很多系統都是這樣實現的；尤其那些快速開發系統； 但是抽象度低， 容易導致重複代碼多，與其他系統的耦合程度高， 維護麻煩，尤其是對於複雜的系統來說。 舉個例子來說，購買商品購買這個功能，案頭版提供了之後，手機版的也需要實現， 由於手機版與案頭版是兩個不同的用例， 如果用事務指令碼來組織代碼的話， 很自然的就會出現類似的代碼出現在了不同的地方的情況。 一個很明顯的最佳化是封裝成函數， 但是封裝成函數這個事情的模組化程度低， 在業務複雜的情況下， 對商務邏輯的有效管理和維護是一個挑戰。

事務指令碼這種方式適用於相對簡單的商務邏輯環境，而且在現實中， 很多業務本身就是簡單的， 這種方式可以在開發高效， 運行高效的前提下工作的很好； 另外對於快速開發環境中也非常適用。 但是當商務邏輯複雜， 而且上線後維護期很長或維護量很大的系統來說，可能不是一種很好的方式。

表模組方式

在事務指令碼方式當中，很容易導致:

1. 相同或者類似的代碼重複出現;
2. 相關邏輯分布在多個地方。對於前一個問題， 可以通過把相同或者相似邏輯封裝成函數來改進， 第二個問題通過流程或規範可以得到控制。 但是， 還是會在業務複雜的情況下對商務邏輯的有效管理和維護是一個挑戰 因為缺乏一種有效編碼的機制來控制這樣的問題。

表模組組織方可以從機制上提供一個相對好的解決辦法， 其大概思路是，把與一個或者多個資料庫表(或者視圖)有關的邏輯組織成一個類， 把對與這個表有關的邏輯組織成這個類的方法。以上面那個購買商品為例， 查詢商品是否足夠可能是一個單獨的方法， 修改商品數量是一個單獨的方法；購買商品是一個方法，所完成的事情就是把前面兩個方法組織起來。 一旦有了這個邏輯， 只要是需要用到購買商品邏輯的地方， 直接調用這個購買商品的方法就可以了； 除了這個購買商品之外， 其他與商品有關邏輯都組織在這個類裡面，避免了與商品有關的邏輯分布到多個地方。

除了提供一個程式碼群組織的方式外，這種組織方式還有一些其他的好處：不需要資料庫表就直接可以測試，也便於打樁測試； 與很多數語言提供的資料庫操作API配合使用方便， 很多資料庫操作API返回的結果都市記錄集的方式， 尤其以微軟提供的相關API為典型代表， .NET提供的Dataset更是功能強大。實際上， 微軟提供的開發平台倡導的就是以表模組方式組織邏輯， 並提供了各種便利的開發工具和API； 在管理代碼的有效性和複雜度上有比較好的平衡，他比前面的事務指令碼方式相對繁瑣點， 比後面好提到的領域模型方式簡單很多。

領域模型

領域模型方式組織代碼就是OO的編程思想， 把領域邏輯對象化， 從而達到在複雜的商務邏輯是有好的可擴充性和可維護性。表模組組織方式在管理代碼的有效性和複雜度上有比較好的平衡， 但是在其提供的抽象機制畢竟有限； 在管理複雜的商務邏輯方面有些不給力。比如， 對於不同類型的商品， 其購買邏輯可能不一樣；這時候， 面向對編碼的威力會就能比較好的發揮了， 商品這個例子中， 購買時的行為可能不一樣， 利用多態機制， 對調用者來說可能是透明的。

領域模型這種方式與表模型的方式的區別在於OO的力度不一樣； 表模型以表為單位來組織， 領域模型可能則以表裡面的記錄為單位來組織的， 因此代碼中， 一個表只有一個類執行個體， 而領域模型則會針對一條記錄有個對象。

模型這種方式的優點是便於有效管理複雜性和可擴充性， 對於複雜的商務邏輯以及那種維護周期很長的系統來說比較適用； 但其缺點也很明： OO建模複雜，開發週期相對會長些；學習成本高， 尤其對於新團隊來說； 同樣， 如果程式碼群組織不好， 也會出現其他方式中出現的類似問題， 如代碼重複等。

小結

三種不同的邏輯組織方式各有特點， 適用於不同的場合， 可以根據實際情況選擇， 一般來說， 簡單應用， 要求快速開發快， 維護周期短的可以考慮事務指令碼方式； 商務邏輯複雜， 維護周期長時， 在開發人員技能滿足的條件下可以考慮領域模型； 在這個兩個中間的情況可以考慮表模組方式， 尤其是在微軟的平台上。 在實際中，由於實際業務的複雜性， 很多時候以一種單一的方式組織還不夠， 可能幾個方式綜合起來運用。 比如， 把核心業務按領域對象的方式組織， 之上再以事務指令碼來組織多變的應用業務。

 

 

來源：http://www.youalab.com/?p=458