前篇：http://www.cnblogs.com/leoo2sk/archive/2009/10/29/1592568.html

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、結束語

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

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

參考文獻

[1] [意]Dino Esposito, Andrea Saltarello, .NET軟體架構之美英文版(原名Microsoft .NET Architecting Application for the Enterprise), 人民郵電出版社, 2009

[2] [美]Martin Fowler, 企業應用架構模式影印版(原名Patterns of Enterprise Application Architecture), 中國電力出版社, 2004

[3] [美]Mclaughlin, Pollice, West, 深入淺出面向物件分析與設計影印版(原名Head First OOA&D), 東南大學出版社, 2007

[4] Google,www.google.com

本文基於署名-非商業性使用 3.0許可協議釋出，歡迎轉載，演繹，但是必須保留本文的署名張洋（包含連結），且不得用於商業目的。如您有任何疑問或者授權方面的協商，請與我聯絡。