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

　　3、業(yè)務邏輯的架構(gòu)模式及實現(xiàn)

　　 Martin Fowler在《Patterns of Enterprise Application Architecture》一書中，總結(jié)了四種企業(yè)應用中業(yè)務邏輯的組織方式 ：Transcation Script，Domain Model，Table Module及Service Layer，另外，本書的第十章“Data Source Architecture Patterns”中包含一種模式——Active Record。結(jié)合軟件體系結(jié)構(gòu)的近期發(fā)展及個人的理解，我更傾向?qū)ctive Record歸入業(yè)務邏輯的組織模式，而Service Layer應該不算做業(yè)務邏輯特有的模式，所以，在本文中，將介紹四種模式：Transcation Script，Table Module，Active Record及Domain Model。

　　3.1、Transction Script

      3.1.1、概述

      Transction Script（以下簡稱TS）是一種面向過程的業(yè)務邏輯組織方式。這里首先要強調(diào)一點，這里的Transction一詞與數(shù)據(jù)庫系統(tǒng)中表示“事務”的Transction沒有任何聯(lián)系。TS是將領(lǐng)域中的業(yè)務分解為一個個業(yè)務過程，每個過程實現(xiàn)一項業(yè)務功能，具體到程序中，一個業(yè)務過程往往映射到一個方法。TS是完全面向過程的業(yè)務組織模式，適合應用于業(yè)務邏輯較簡單的場合。

      應該說，我們見到的絕大多數(shù)系統(tǒng)都是以TS組織業(yè)務的。例如PetShop及Oxite等經(jīng)典示例。有時為了方便維護，開發(fā)者會將同一領(lǐng)域?qū)嶓w相關(guān)的業(yè)務方法集中到一個類中，這里雖然用到了領(lǐng)域?qū)嶓w和類的概念，但和面向?qū)ο鬀]有任何關(guān)系，完全是面向過程的。

      當使用TS時，可以不需要數(shù)據(jù)訪問層，而是將數(shù)據(jù)操作執(zhí)行代碼（如執(zhí)行SQL或存儲過程的代碼）直接嵌入在業(yè)務方法中，有時為了復用性和維護性可以編寫一個helper類封裝數(shù)據(jù)庫的操作。當然這并不是說TS不能配合數(shù)據(jù)訪問層使用，但由于應用TS的場合一般業(yè)務非常簡單，如果配合Repository或ORM使用，業(yè)務邏輯層往往就會變得非常“瘦”，看起來僅僅是對數(shù)據(jù)訪問層的封裝。一般在需要支持多數(shù)據(jù)庫的場合，要配合Repository和Abstract Factory使用。

      TS的示意圖如下所示：

圖3-1、 Transcation Script架構(gòu)示意

　　可以看到，在TS中，業(yè)務層并沒有面向?qū)ο蟮臇|西。也許會用到類，但類只是組織業(yè)務方法的模塊，每個模塊中有一個個業(yè)務方法，每個業(yè)務方法完成一個業(yè)務流程，完全按面向過程結(jié)構(gòu)組織。

      3.1.2、分析

• 什么時候可以用TS？

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

      1）系統(tǒng)業(yè)務十分簡單直觀，并且頻繁變動的可能性不大

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

      3）不能熟練掌握和使用OO進行系統(tǒng)的設計與開發(fā)

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

• TS的優(yōu)點？

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

      2）在業(yè)務比較簡單直觀的情況下，TS結(jié)構(gòu)的代碼直觀易懂，具有良好的可維護性

• TS的缺點？

      1）容易造成代碼冗余。因為各個業(yè)務自行組織流程，所以減少了復用的機會，可能產(chǎn)生重復性代碼

      2）因為TS天生不適合業(yè)務復雜的系統(tǒng)，當系統(tǒng)業(yè)務較復雜時，可能會令業(yè)務層代碼繁雜不堪

　　3.2、Table Module

　　3.2.1、概述

      Table Module（以下簡稱TM）同樣是一種面向過程的業(yè)務邏輯組織方式，與TS不同的是，TM更貼近關(guān)系型數(shù)據(jù)庫結(jié)構(gòu)。在TS中，一般使用DTO等進行數(shù)據(jù)表示和傳遞，其著眼點一般在單個對象。而TM一般根據(jù)數(shù)據(jù)表組織業(yè)務模塊，每個模塊對應一個表，其中包含了這個表的相應處理。并且在業(yè)務層內(nèi)，使用庫-表結(jié)構(gòu)的對象進行數(shù)據(jù)操作，做到最大限度與數(shù)據(jù)表的對應。業(yè)務組織一般按照面向過程組織。

      一般當業(yè)務相對簡單且業(yè)務基本集中在CRUD操作時，可以考慮TM。使用TM意味著使用數(shù)據(jù)驅(qū)動設計。通常自己實現(xiàn)一套庫-表結(jié)構(gòu)操作對象的庫是難度比較大的，所以一般選用TM時，所使用的平臺應該包括這么一套庫。如.NET平臺上的ADO.NET就內(nèi)置了豐富的庫-表操作，DataSet，DataTable，DataAdapter等在TM架構(gòu)的實現(xiàn)中可以起到非常方便的作用。

      使用TM后，一般不需要再配合Reponsitory或ORM，因為此時的業(yè)務層也是面向過程和面向關(guān)系型結(jié)構(gòu)的，無須映射。

      TM的示意圖如下：

圖3-2、Table Module架構(gòu)示意 

      在使用TM后，業(yè)務代碼中往往有各種對象對應數(shù)據(jù)庫中的庫、表、記錄、字段等元素，并提供類似關(guān)系數(shù)據(jù)庫的操作。

　　3.2.2、分析

• 什么時候可以用TM？

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

      1）系統(tǒng)業(yè)務較直觀，以CRUD操作比較集中

      2）整個開發(fā)的指導思想是數(shù)據(jù)驅(qū)動

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

• TM的優(yōu)點？

      1）類似關(guān)系數(shù)據(jù)庫的數(shù)據(jù)操作方式非常直觀，使得設計和編寫數(shù)據(jù)操作功能的代碼簡單高效

• TM的缺點？

      1）TM需要完全的數(shù)據(jù)驅(qū)動，從業(yè)務到UI傳遞、存放數(shù)據(jù)都要以表結(jié)構(gòu)形式，造成一定程度上的不靈活

      2）當業(yè)務并非CRUD集中型操作，特別是領(lǐng)域模型和數(shù)據(jù)庫表模型差異較大時，使用TM組織業(yè)務的難度非常大

　　3.3、Active Record

　　3.3.1、概述

      Active Record（以下簡稱AR）是一種面向?qū)ο蟮臉I(yè)務邏輯組織方式。AR適用于在業(yè)務較簡單的情況下，應用面向?qū)ο笏枷脒M行設計。它的基本思想就是將領(lǐng)域中每個實體抽象出一個業(yè)務類（BO），然后，將這個實體的數(shù)據(jù)和行為封裝成類的屬性和方法。特別的，將CRUD功能也封裝進BO中。也就是說，AR中的BO同時具備業(yè)務方法和持久化功能。其本身具有ORM的特性，其內(nèi)部要處理關(guān)系實體間的關(guān)聯(lián)問題。

      使用AR時，一般最好有相應框架支持，否則完全手工實現(xiàn)AR有點麻煩。像Castle框架中就有AR功能，Linq to sql也有AR的意思。使用AR后，一般不需要再單獨使用數(shù)據(jù)訪問層。

      AR的組織架構(gòu)如下圖：

 圖3-3、Active Record架構(gòu)示意

      從圖3-3中可以看出，AR對業(yè)務領(lǐng)域進行了一個簡單的OO抽象，將各個實體抽象為AR業(yè)務對象，AR業(yè)務對象內(nèi)含有數(shù)據(jù)、業(yè)務方法及數(shù)據(jù)訪問相關(guān)的ORM方法。另外，AR業(yè)務對象要維護實體間簡單的一對多和多對多等關(guān)系。

　　3.3.2、分析

• 什么時候可以用AR？

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

      1）系統(tǒng)業(yè)務較直觀

      2）想嘗試使用或習慣于使用OO進行系統(tǒng)設計與實現(xiàn)

      3）平臺上有成熟的AR框架可以用

• AR的優(yōu)點？

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

      2）使用AR后，與某個實體相關(guān)的數(shù)據(jù)和業(yè)務全部集中于AR業(yè)務對象中，模塊內(nèi)聚性好，便于維護

      3）實踐證明，AR結(jié)構(gòu)的業(yè)務層編碼效率很高

• AR的缺點？

      1）AR仍需要關(guān)注數(shù)據(jù)之間的關(guān)聯(lián)，在一定程度上帶有數(shù)據(jù)表和影子，沒有完全擺脫數(shù)據(jù)驅(qū)動，所以當業(yè)務領(lǐng)域和數(shù)據(jù)庫結(jié)構(gòu)差距大時，實施困難

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

      3）如果業(yè)務非常復雜，AR將力不從心

　　3.4、Domain Model

　　3.4.1、概述

      Domain Model（以下簡稱DM）是一種適合領(lǐng)域驅(qū)動和為復雜業(yè)務系統(tǒng)組織業(yè)務的面向?qū)ο髽I(yè)務邏輯組織方式。前面三種架構(gòu)模式都有一個共同的缺點——不適合業(yè)務復雜的系統(tǒng)。那么何為復雜何為簡單？很抱歉，我給不出明確答案，而且我估計世界上任何一個人都很難給出標準的無爭議答案。因為軟件系統(tǒng)中的復雜和簡單本身就是一個難以量化的指標，很多時候，只能靠專業(yè)人員的經(jīng)驗了。

      我個人估計，世界上95%的軟件系統(tǒng)其業(yè)務難度都不會超出上述三種模式的能力范圍，而若你不幸遇到剩下的5%，恐怕目前只有Domain Model能幫你了。Domain Model是一種純面向?qū)ο蟮臉I(yè)務架構(gòu)模式，它的核心思想是獲取領(lǐng)域中的各種實體抽象，然后完全按照現(xiàn)實領(lǐng)域中的情況去建模和運行。并且業(yè)務對象是“持久化無知”的。關(guān)于“持久化無知”下面細討論。這個模式十分復雜和難以掌握，但一旦掌握并使用，其能力絕對會超乎你的想象。

      下面看一下DM的架構(gòu)示意圖：

  圖3-4、Domain Model架構(gòu)示意

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

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

      第一，DM中的業(yè)務對象是純業(yè)務對象，不含數(shù)據(jù)訪問操作。這個可以和AR中的業(yè)務對象對比一下。也就是說，DM中的業(yè)務對象是純業(yè)務對象，它們只關(guān)注與業(yè)務的實現(xiàn)。

      第二，DM的組織內(nèi)部對象多，關(guān)系復雜，而這種關(guān)系不再只是那種簡單的一對一、一對多的關(guān)系，而是領(lǐng)域中的各種依賴和關(guān)聯(lián)的抽象，關(guān)系類型多，非常復雜。

      第三，DM需要業(yè)務部分“持久化無知”。所謂持久化無知，指業(yè)務部分只需執(zhí)行業(yè)務功能，而不必關(guān)系持久化。在使用DM時，必須設計一套ORM機制（注意這里用到了“機制”一詞，而不是“框架”或“庫”），使得在業(yè)務系統(tǒng)運行時，自動在必要的時候執(zhí)行數(shù)據(jù)持久化操作。這也是為什么上圖數(shù)據(jù)源和業(yè)務層間的箭頭是虛線的關(guān)系。

      上文曾說過，DM要最大程度模擬現(xiàn)實情況。而現(xiàn)實世界和軟件世界最大的區(qū)別就是現(xiàn)實世界是“內(nèi)存無限大、永不停機的”，可以把現(xiàn)實世界看成在一個無限大內(nèi)存里永不停止運行的程序。而軟件世界不同，它的內(nèi)存有限制，我們不能將所有對象都放在內(nèi)存，而且一旦掉電，它就會停止運行，正因如此，我們才需要持久化機制去配合DM模擬現(xiàn)實世界。為了讓業(yè)務更接近現(xiàn)實，它必須對持久化過程毫無感覺。而一套持久化機制默默為其營造了一個好似內(nèi)存無限大、永不停機的環(huán)境，因此DM才得以發(fā)揮威力。

      第四，DM往往需要Services Layer的配合。因為DM內(nèi)部僅有一個個業(yè)務對象，它們互相調(diào)用，并沒有提供一個友好的接口與UI交互，所以在使用DM時，往往在其上對各種UI需要的服務進行封裝（回顧一下Facade模式），形成一個Services Layer，以方便與UI交互。

　　3.4.2、分析

• 什么時候可以用DM？

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

      1）系統(tǒng)業(yè)務極為復雜

      2）有功底扎實和經(jīng)驗豐富的精通OO的架構(gòu)及設計師

      3）項目經(jīng)費和時間充足

      4）貫徹領(lǐng)域驅(qū)動設計

• DM的優(yōu)點？

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

      2）應付復雜業(yè)務的強力殺手锏。如果DM運用得當，將會使得復雜業(yè)務被高效解決

• DM的缺點？

      1）使用門檻極高，難度極大，如果團隊中沒有精通OO和系統(tǒng)架構(gòu)且經(jīng)驗豐富的專家很難實施

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

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

　　3.5、各種架構(gòu)模式的比較及選擇

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

圖3-5、業(yè)務架構(gòu)模式?jīng)Q策網(wǎng)絡

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

　　4、結(jié)束語

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

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

　　參考文獻

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

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

　　[3] [美]Mclaughlin, Pollice, West, 深入淺出面向?qū)ο蠓治雠c設計影印版(原名Head First OOA&D), 東南大學出版社, 2007

　　[4] Google, www.google.com

it知識庫：細說業(yè)務邏輯（后篇），轉(zhuǎn)載需保留來源！

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