前篇：http://kb.cnblogs.com/page/50470/

　　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