細說商務邏輯（二）

標籤：

3、商務邏輯的架構模式及實現

　　 Martin Fowler在《Patterns of Enterprise Application Architecture》一書中，總結了四種公司專屬應用程式中商務邏輯的組織方式 ：Transcation Script，Domain Model，Table Module及Service Layer，另外，本書的第十章“Data Source Architecture Patterns”中包含一種模式——Active Record。結合軟體體繫結構的近期發展及個人的理解，我更傾向將Active Record歸入商務邏輯的組織模式，而Service Layer應該不算做商務邏輯特有的模式，所以，在本文中，將介紹四種模式：Transcation Script，Table Module，Active Record及Domain Model。

　　3.1、Transction Script

      3.1.1、概述

      Transction Script（以下簡稱TS）是一種面向過程的商務邏輯組織方式。這裡首先要強調一點，這裡的Transction一詞與資料庫系統中表示“事務”的Transction沒有任何聯絡。TS是將領域中的業務分解為一個個業務過程，每個過程實現一項業務功能，具體到程式中，一個業務過程往往映射到一個方法。TS是完全面向過程的業務組織模式，適合應用於商務邏輯較簡單的場合。

      應該說，我們見到的絕大多數系統都是以TS組織業務的。例如PetShop及Oxite等經典樣本。有時為了方便維護，開發人員會將同一領域實體相關的業務方法集中到一個類中，這裡雖然用到了領域實體和類的概念，但和物件導向沒有任何關係，完全是面向過程的。

      當使用TS時，可以不需要資料訪問層，而是將資料操作執行代碼（如執行SQL或預存程序的代碼）直接嵌入在業務方法中，有時為了複用性和維護性可以編寫一 個helper類封裝資料庫的操作。當然這並不是說TS不能配合資料訪問層使用，但由於應用TS的場合一般業務非常簡單，如果配合Repository或 ORM使用，商務邏輯層往往就會變得非常“瘦”，看起來僅僅是對資料訪問層的封裝。一般在需要支援多資料庫的場合，要配合Repository和 Abstract Factory使用。

      TS的如下所示：

圖3-1、 Transcation Script架構示意

　　可以看到，在TS中，業務層並沒有物件導向的東西。也許會用到類，但類只是組織業務方法的模組，每個模組中有一個個業務方法，每個業務方法完成一個商務程序，完全按面向過程結構組織。

      3.1.2、分析

• 什麼時候可以用TS？

      應該說，如果具備以下條件之一，你可以考慮TS：

      1）系統業務十分簡單直觀，並且頻繁變動的可能性不大

      2）工期很緊，需要盡量壓縮設計的時間，儘快投入編碼

      3）不能熟練掌握和使用OO進行系統的設計與開發

      4）厭惡OO，就是喜歡面向過程

• TS的優點？

      1）設計階段投入較小，啟動耗費低。因為TS較容易掌握，使用起點低，所以使用TS的初期投入較少

      2）在業務比較簡單直觀的情況下，TS結構的代碼直觀易懂，具有良好的可維護性

• TS的缺點？

      1）容易造成代碼冗餘。因為各個業務自行組織流程，所以減少了複用的機會，可能產生重複性代碼

      2）因為TS天生不適合業務複雜的系統，當系統業務較複雜時，可能會令業務層代碼繁雜不堪

　　3.2、Table Module

　　3.2.1、概述

      Table Module（以下簡稱TM）同樣是一種面向過程的商務邏輯組織方式，與TS不同的是，TM更貼近關係型資料庫結構。在 TS中，一般使用DTO等進行資料表示和傳遞，其著眼點一般在單個對象。而TM一般根據資料表組織業務模組，每個模組對應一個表，其中包含了這個表的相應 處理。並且在業務層內，使用庫-表結構的對象進行資料操作，做到最大限度與資料表的對應。業務組織一般按照面向過程組織。

      一般當業務相對簡單且業務基本集中在CRUD操作時，可以考慮TM。使用TM意味著使用資料驅動設計。通常自己實現一套庫-表結構操作對象的庫是難度比較 大的，所以一般選用TM時，所使用的平台應該包括這麼一套庫。如.NET平台上的ADO.net就內建了豐富的庫-表操 作，DataSet，DataTable，DataAdapter等在TM架構的實現中可以起到非常方便的作用。

      使用TM後，一般不需要再配合Reponsitory或ORM，因為此時的業務層也是面向過程和面向關係型結構的，無須映射。

      TM的如下：

圖3-2、Table Module架構示意 

 

      在使用TM後，業務代碼中往往有各種對象對應資料庫中的庫、表、記錄、欄位等元素，並提供類似關聯式資料庫的操作。

　　3.2.2、分析

• 什麼時候可以用TM？

      如果同時具備以下條件，你可以考慮TM：

      1）系統業務較直觀，以CRUD操作比較集中

      2）整個開發的指導思想是資料驅動

      3）所選用的平台有成熟的庫-表操作庫支援

• TM的優點？

      1）類似關聯式資料庫的資料操作方式非常直觀，使得設計和編寫資料操作功能的代碼簡單高效

• TM的缺點？

      1）TM需要完全的資料驅動，從業務到UI傳遞、存放資料都要以表結構形式，造成一定程度上的不靈活

      2）當業務並非CRUD集中型操作，特別是領域模型和資料庫表模型差異較大時，使用TM組織業務的難度非常大

　　3.3、Active Record

　　3.3.1、概述

      Active Record（以下簡稱AR）是一種物件導向的商務邏輯組織方式。AR適用於在業務較簡單的情況下，應用物件導向思想進行設計。它的基本思想就是將領域中每個實體抽象出一個業務類（BO），然後，將這個實體的資料和行為封裝成類的屬性和方法。特別的，將CRUD功能也封裝進BO中。也就是說，AR中的BO同時具備業務方法和持久化功能。其本身具有ORM的特性，其內部要處理關係實體間的關聯問題。

      使用AR時，一般最好有相應架構支援，否則完全手工實現AR有點麻煩。像Castle架構中就有AR功能，Linq to sql也有AR的意思。使用AR後，一般不需要再單獨使用資料訪問層。

      AR的組織架構如：

 圖3-3、Active Record架構示意

      從圖3-3中可以看出，AR對業務領域進行了一個簡單的OO抽象，將各個實體抽象為AR業務對象，AR業務對象內含有資料、業務方法及資料訪問相關的ORM方法。另外，AR業務對象要維護實體間簡單的一對多和多對多等關係。

　　3.3.2、分析

• 什麼時候可以用AR？

      如果同時具備以下條件，你可以考慮AR：

      1）系統業務較直觀

      2）想嘗試使用或習慣於使用OO進行系統設計與實現

      3）平台上有成熟的AR架構可以用

• AR的優點？

      1）使用OO的方式進行設計與實現，能在一定程度上避免冗餘代碼問題）

      2）使用AR後，與某個實體相關的資料和業務全部集中於AR業務對象中，模組內聚性好，便於維護

      3）實踐證明，AR結構的業務層編碼效率很高

• AR的缺點？

      1）AR仍需要關注資料之間的關聯，在一定程度上帶有資料表和影子，沒有完全擺脫資料驅動，所以當業務領域和資料庫結構差距大時，實施困難

      2）AR的CRUD是以個體為粒度的，當進行大量操作時，如一次查數千個資料，如果嚴格尊從AR就需要產生數千個AR業務對象，這簡直是場災難。所以在有大規模查詢的情況下，可以考慮使用TS配合AR

      3）如果業務非常複雜，AR將力不從心

　　3.4、Domain Model

　　3.4.1、概述

      Domain Model（以下簡稱DM）是一種適合領域驅動和為複雜業務系統組織業務的物件導向商務邏輯組織方式。前面三種架構模式都有一個共同的缺點——不適合業務 複雜的系統。那麼何為複雜何為簡單？很抱歉，我給不出明確答案，而且我估計世界上任何一個人都很難給出標準的無爭議答案。因為軟體系統中的複雜和簡單本身 就是一個難以量化的指標，很多時候，只能靠專業人員的經驗了。

      我個人估計，世界上95%的軟體系統其業務難度都不會超出上述三種模式的能力範圍，而若你不幸遇到剩下的5%，恐怕目前只有Domain Model能幫你了。Domain Model是一種純物件導向的業務架構模式，它的核心思想是擷取領域中的各種實體抽象，然後完全按照現實領域中的情況去建模和運行。並且業務對象是“持久化無知”的。關於“持久化無知”下面細討論。這個模式十分複雜和難以掌握，但一旦掌握並使用，其能力絕對會超乎你的想象。

      下面看一下DM的架構：

  圖3-4、Domain Model架構示意

      從圖3-4中可以看出，DM看上去是個十分糾結的模式，而實際上，它確實很糾結！實際上，我認為如果能熟練掌握並運用DM進行商務邏輯的組織，那這人絕對是架構師中的大師級人物（我目前是做不到）。

      還是先結合圖示分析一下DM中的要點。

      第一，DM中的業務對象是純業務對象，不含資料訪問操作。這個可以和AR中的業務對象對比一下。也就是說，DM中的業務對象是純業務對象，它們只關注與業務的實現。

      第二，DM的組織內部對象多，關係複雜，而這種關係不再只是那種簡單的一對一、一對多的關係，而是領域中的各種依賴和關聯的抽象，關聯類型多，非常複雜。

      第三，DM需要業務部分“持久化無知”。所謂持久化無知，指業務部分只需執行業務功能，而不必關係持久化。在使用DM時，必須設計一套ORM機制（注意這 裡用到了“機制”一詞，而不是“架構”或“庫”），使得在業務系統運行時，自動在必要的時候執行資料持久化操作。這也是為什麼資料來源和業務層間的箭頭 是虛線的關係。

      上文曾說過，DM要最大程度類比現實情況。而現實世界和軟體世界最大的區別就是現實世界是“記憶體無限大、永不停機的”，可以把現實世界看成在一個無限大內 存裡永不停止啟動並執行程式。而軟體世界不同，它的記憶體有限制，我們不能將所有對象都放在記憶體，而且一旦掉電，它就會停止運行，正因如此，我們才需要持久化機 制去配合DM類比現實世界。為了讓業務更接近現實，它必須對持久化過程毫無感覺。而一套持久化機制默默為其營造了一個好似記憶體無限大、永不停機的環境，因 此DM才得以發揮威力。

      第四，DM往往需要Services Layer的配合。因為DM內部僅有一個個業務對象，它們互相調用，並沒有提供一個友好的介面與UI互動，所以在使用DM時，往往在其上對各種UI需要的 服務進行封裝（回顧一下Facade模式），形成一個Services Layer，以方便與UI互動。

　　3.4.2、分析

• 什麼時候可以用DM？

      如果同時具備以下條件，你可以考慮DM：

      1）系統業務極為複雜

      2）有功底紮實和經驗豐富的精通OO的架構及設計師

      3）項目經費和時間充足

      4）貫徹領域驅動設計

• DM的優點？

      1）完全的OO思想運用，將使你享受到OO的所有優勢

      2）應付複雜業務的強力殺手鐧。如果DM運用得當，將會使得複雜業務被高效解決

• DM的缺點？

      1）使用門檻極高，難度極大，如果團隊中沒有精通OO和系統架構且經驗豐富的專家很難實施

      2）設計過程極為複雜，可能會導致設計癱瘓

      3）如何設計良好的ORM機制輔助DM是一大難題

　　3.5、各種架構模式的比較及選擇

      相信看過上文內容後，各位一定對各種業務組織模式及其特點、優劣、應用情境有了清晰地認識，如果我在這裡再喋喋不休討論各種模式的比較及如何選擇，難免有 侮辱各位智商之嫌O(∩_∩)O~，所以這裡我只給大家呈現一幅決策網狀圖，以期起到一個梳理和歸納總結的作用。

圖3-5、業務架構模式決策網路

      （鄭重聲明：圖3-5為本人原創，並非摘錄自已有文 獻，因此此圖的選型流程僅代表個人意見。由於筆者水平有限，不能保證此圖一定合理和正確。因此在實際選型時請多多參考已有文獻及諮詢相關專家，此圖只起總 結歸納和探討作用，不作為任何指導和規範。若因遵循此圖選型而給項目帶來的任何經濟及其他方面損失，筆者不承擔任何責任。）

　　4、結束語

      本文通過兩篇文章的篇幅，先後介紹了商務邏輯的定義、相關理論及經典的商務邏輯相關的架構模式。本文中闡述了不少已有理論，亦摻雜諸多個人理解及看法。因此請各位在閱讀時多進行批判吸收，同時參考以後經典文獻及書目綜合理解商務邏輯，切勿僅看我一家之言。

      另外，由於本文僅僅是綜述性文章，不能具名商務邏輯的各個方面，在深度上也基本是淺嘗輒止。因此，若希望深入理解商務邏輯，可以看到相關經典書籍及文獻。

 

本文轉載至：http://kb.cnblogs.com/page/50527/

細說商務邏輯（二）