仍是隨便寫寫，順便摘抄如下他人成果。——什麼是業務邏輯

注：此文是拾人牙慧，用做自我學習！

 

前言

記得幾個月前，在一次北京博客園俱樂部的活動上，最後一個環節是話題自由討論。就是提幾個話題，而後你們各自加入感興趣的話題小組，進行自由討論。當時金色海洋同窗提出了一個話題——「什麼是業務邏輯」。當時我和你們討論ASP.NET MVC的相關話題去了，就沒能加入「業務邏輯」組的討論，比較遺憾。

其實，一段時間內，我腦子裏對「業務邏輯」的概念也是很是模糊的。但在不斷地閱讀、思考和實踐過程當中，這個概念及其相關的內容纔在我腦子裏漸漸清晰。我想，不少朋友也許也對這個概念不是很瞭解，因此願意結合既有資料和本身的思考，總結一篇關於業務邏輯的概述性文章，一則與朋友們分享探討，二則也是爲本身對業務邏輯的學習作一個總結和提高。由於我還不敢說對業務邏輯內涵及外延理解的很是充分，因此文中若有不當之處，還請各位不用客氣，儘管批評就好！

內容提要

===================前篇=====================

前言

內容提要

一、我把業務邏輯丟了！——找回丟失的業務邏輯

二、細說業務邏輯

  2.一、業務邏輯究竟是什麼

  2.二、業務邏輯的組成結構

   2.2.一、領域實體（Domain Entity）

   2.2.二、業務規則（Business Rules）

   2.2.三、完整性約束（Validation）

   2.2.四、業務流程及工做流（Business Processes and Workflows）

  2.三、業務邏輯層職責相關爭議

   2.3.一、爭議一：數據的格式化

   2.3.二、爭議二：數據合法性及完整性驗證

   2.3.三、爭議三：CRUD

   2.3.四、爭議四：存儲過程

===================後篇=====================

三、業務邏輯的架構模式及實現

  3.一、Transcaton Script

   3.1.一、概述

   3.1.二、分析

  3.二、Table Module

   3.2.一、概述

   3.2.二、分析

  3.三、Active Record

   3.3.一、概述

   3.3.二、分析

  3.四、Domain Model

   3.4.一、概述

   3.4.二、分析

  3.五、各類架構模式的比較及選擇

四、結束語

參考文獻

一、我把業務邏輯丟了！——找回丟失的業務邏輯

相信朋友們基本都是軟件開發人員。不論身處什麼職位，咱們的工做都有一個共同的目標——製做軟件產品。而所謂的軟件產品，必定是在某個領域內去實現某些業務 。如此看來，「業務邏輯」本應和「軟件產品」是牢牢綁在一塊兒的，沒有業務邏輯，何來軟件產品？

可是，我發現一個奇怪的現象，一說業務邏輯，不少人就沒法造成清晰地印象。例如，經典的三層架構：表示層、業務邏輯層和數據訪問層，一提到表示層或數據訪問層，你們腦子裏立刻能產生出清晰的概念，但一提到業務邏輯層，就有點模糊了，或者徹底不知道其是什麼，或者有個模糊的輪廓，但對其具體的職責、結構不是很清楚。真是奇了怪了！咱們每天和業務邏輯打交道，搞不清業務邏輯是什麼。

對於這個奇怪的現象，我思前想後，結合自身的教訓（我也曾很長時間搞不清業務邏輯），終於弄清楚了其緣由——這和咱們接觸這個概念的途徑和認知結構有莫大關係。

不知道有多少人和我同樣，首次接觸「業務邏輯」這個概念是從分層架構中的「業務邏輯層」概念開始的，我相信不在少數。事情壞就壞在這裏！爲了讓朋友們直觀看清「業務邏輯」的概念是怎麼被咱們丟掉的，請你們看一個圖，這個圖展現了不少人對「業務邏輯」的認知過程。

圖 1-一、狹義的認知分解過程

如圖1-1所示，咱們先接觸了分層架構，而後對每一個層產生了初步的認識。其中，因爲表示層和數據訪問層的代碼職責清晰明確，基本能正確認識。可是，因爲咱們接觸的分層架構的Demo大多業務極其簡單，又基本是CRUD操做集中型的業務。因此，咱們腦子中就產生了疑問：這個所謂的業務邏輯層是幹什麼的？怎麼就簡單封裝了一下數據訪問層的操做？這有存在的必要嗎？因爲有了這種「先入爲主」的誤導，使得不少朋友腦中將「業務邏輯」和「業務邏輯層」兩個概念混淆了，始終想不明白這東西究竟是什麼，作什麼用的。再加上不少朋友所看的、所作的系統都是CRUD操做集中型的，就造成了「業務邏輯貌似就是對數據訪問操做的簡單封裝」這一片面概念。

到底這一律念有沒有錯呢？其實沒錯，由於在簡單的、CRUD操做集中型軟件中，業務邏輯基本就是對數據訪問簡單的封裝。可是，無錯不表明全面，這是一種狹義的業務邏輯理解，並且是狹義中的狹義。爲何這麼說呢？由於咱們不可是在「業務邏輯層」這麼一個狹義範圍內去理解業務邏輯，並且仍是CRUD集中型操做這種「很是瘦」的業務邏輯層範圍內去理解，因此，可謂是在狹義的基礎上的狹義。

當咱們把這麼一個「狹義中的狹義業務邏輯」與「業務邏輯」等同起來時，誤會、迷茫、困惑、不屑就出現了。這就如同，給你一隻溫順的哈巴狗，仍是病怏怏的、無精打彩的小哈巴狗，而你把這隻「病怏怏的小哈巴狗」與「狗」的概念等同起來了。那麼你必定就會爲有人養狗看家和警察養狗當警犬抓壞人而困惑：這東西這麼弱小，我一腳就踩死了，怎麼弄用來看家和抓壞人呢？進而可能會產生「狗狗無用論」，「狗狗廢品」等觀念。固然，在現實中，不多有人只見太小哈巴狗而沒見過狼狗等其它狗類，因此，故事中的誤會對 「狗」通常是不存在的。但在現實中，確實有不少人只見過業務邏輯中的「小哈巴狗」，卻沒有見過業務邏輯中的「狼狗」、「藏獒」，因此，這種誤會在對「業務邏輯」的理解上普遍存在。

那麼，廣義的狀況到底是怎麼樣的？請看下圖。

圖 1-二、廣義的認知分解過程

（注意！凡是不特別說明，下文中全部「數據」一詞都指須要持久化的數據，而不包括內存中的臨時數據。請各位留心。）

如圖1-2所示，廣義的認知分解應該是這樣的：軟件產品都是在某個領域內實現某些特定業務，因此，軟件產品天生應該分解爲界面交互部分和業務邏輯部分，其中業務邏輯部分是軟件產品的核心，它客觀存在於軟件產品內部，可是沒法對使用者產生直觀刺激，所以業務邏輯不能與使用者直接交互。而界面交互部分是業務邏輯與使用者進行交流的接口，使用者經過界面交互部分，與業務進行交流，從而使得軟件產品發揮其做用。

而在具體實現系統時，界面交互部分演化成表示層，業務邏輯部分演化成業務邏輯層。因此，能夠認爲，數據訪問層不是軟件產品天然演化的直接產物，之因此出現數據訪問層，是由於某些產品的業務屬於「數據操做集中型」業務，爲了實現隔離、複用等目的，架構師從業務邏輯中分離出了頻繁使用的數據訪問業務，造成了單獨的數據訪問層。從廣義來講，能夠認爲數據訪問隸屬於業務邏輯，由於，數據訪問操做實際上也是業務邏輯的一部分。

總結一下幾個要點：（這幾個要中的業務邏輯均指廣義業務邏輯）

1）軟件產品天然的可分爲界面交互部分和業務邏輯部分。

2）從空間結構上看，業務邏輯和數據訪問不是並列關係，而是隸屬關係——數據訪問隸屬於業務邏輯。雖然在具體系統實現層面，數據訪問層和業務邏輯層是並列存在，但從概念本質層面上分析，二者是隸屬關係。

3）從時間結構上看，應該是先有業務邏輯的概念，纔有數據訪問的概念。業務邏輯衍生自軟件自己，數據訪問衍生自業務邏輯。

4）由於業務邏輯是軟件產品天然的一部分，因此擁有業務邏輯是軟件產品的必要條件（讀者能夠試着舉出一個不包含業務邏輯的軟件）。可是一個軟件能夠沒有數據訪問，如「計算器」、「不帶存檔的小遊戲」等。

利用以上論述要點和認知分解，朋友們能夠試試在腦中從新構築狹義和廣義「業務邏輯」的概念。看能不能把咱們丟掉的業務邏輯概念找回來。關於業務邏輯更多的細節，將在下文中討論。

二、細說業務邏輯

2.一、業務邏輯究竟是什麼

在第一大節裏說了那麼多，相信各位基本已經造成「業務邏輯」的概念了。若是我在這裏再囉嗦什麼，我不嫌累各位也要嫌煩了。因此，這裏我僅給出兩個定義。

廣義上的義務邏輯——軟件自己固有的一種品性，天然存在於軟件產品內部，是軟件具備的在某個業務領域內的邏輯，是軟件的核心和靈魂。軟件產品除界面和交互外的一切均可看做是廣義業務邏輯。

狹義上的業務邏輯——等同於分層架構中「業務邏輯層」的職責，是軟件中處理與業務相關任務的部分，通常狹義上的業務邏輯不包含數據持久化，而只關注領域內的相關業務。

對於以上兩種定義，但願朋友們不要割裂開來看，而 要辯證統一的去看，這樣，才能構建一個完整而辯證統一的「業務邏輯」概念。在下文中，將再也不明確區分狹義和廣義，「業務邏輯」一詞將表明二者的辯證統一體。

2.二、業務邏輯的組成結構

業務邏輯做爲一個高層次概念，其內在結構也是很是豐富的，下面咱們深刻其裏，去探尋一下業務邏輯都是由哪些更底層的部分構成的。

2.2.一、領域實體（Domain Entity）

通俗的說，領域實體就是這個領域內有哪些東西。例如，銀行業領域內有帳戶、支票、前臺營業員等實體；B2C電子商務領域有商品、訂單、交易等實體；魔獸世界遊戲的領域內有角色、種族、道具、魔法等實體；高等代數領域有矩陣、行列式等實體。

領域實體是某個領域內各類對象的抽象，能夠用名詞表示（能夠是具體名詞或抽象名詞，甚至動名詞，只要其具備名詞性），構成了整個業務邏輯的骨骼和靜態模型。通常每一個領域實體有本身的一些屬性和行爲。 順便說一句，領域實體的存在時OOA&D的基礎。

在具體的軟件系統中，領域實體每每會根據架構的不一樣有不一樣的映射存在形式。

其中一種叫作Business Object（BO），即業務對象，某些文獻稱其爲「充血實體類」，這種對象完整抽象了領域內的某個實體，封裝了此實體相關屬性和行爲。在面向對象的設計和架構中，這種實體類很常見。

另外一種叫作Data Transfer Object（DTO），某些文獻稱其爲「貧血實體類」，其特色是僅有屬性，不存在行爲。這種實體類主要負責總體性傳遞數據。另外，與BO不一樣的是，DTO能夠不抽象領域實體的所有屬性，而只根據須要抽象一部分。例如，某個「User」實體存在不少屬性，但若是某個方法僅須要其聯繫方式，能夠設計一個DTO，僅有id，email，address，phone等就夠了。在面向過程的設計和架構中，這種實體設計比較常見。

2.2.二、業務規則（Business Rules）

業務規則就是某個領域內運做的規則，構成了整個業務邏輯的靈魂和動態模型。業務規則做用於領域實體，領域實體聽從業務規則進行運做。

如：在銀行領域內，「轉帳時從A帳戶扣除相應款項，在B帳戶添加相應款項，並從A帳戶扣除相應手續費，並經過某些途徑通知A和B帳戶的戶主」就是一條規則。須要注意的是，業務規則比較抽象，並非需求，需求須要具體且無二義性，而業務規則只是抽象的一種描述，例如，通知戶主的途徑是什麼？電子郵件？電話？短信？並無具體描述，但在規則中有「通知」這一項，所以不能將業務規則等同於需求。

2.2.三、完整性約束（Validation）

領域實體和業務規則構建了業務邏輯的主體，但在這主體之上，還存在着一個限制，這就是完整性約束。

完整性約束是對業務領域中的數據、規則的強制性規定與約束。這種約束是系統正常運轉的保證。

如「帳戶密碼不能爲空」，「身份證號必須符合具體格式規定」，「轉帳流程必須具備原子性，A帳戶扣錢、B帳戶存錢、A帳戶扣除手續費、通知戶主四項操做必需要麼都作，要麼都不作」，都是完整性約束。

2.2.四、業務流程及工做流（Business Processes and Workflows）

有了上述三項，業務邏輯還不能正常工做，由於尚未「啓動器」和「過程託管器」。設想咱們有了各類實體類，它們有各自的屬性和行爲，也有定義好的業務規則和完整性約束。如今實體類僅僅具備實現業務規則的能力，但它們如何啓動並交互協調完成業務規則呢？所以咱們須要有東西去觸發和協調實體。

業務流程或工做流是啓動及託管協調領域實體完成既定規則的過程。例如，「在線訂購」是一個業務流程，它包括「用戶登陸-選擇商品-結算-下訂單-付款-確認收貨」這一系列流程。各個實體如會員、訂單、商品等已經包含了完成在線訂購必要的行爲，但仍需一個流程，才能真正完成業務。

具體到程序中，業務流程也許經過一個方法來實現，這個方法負責啓動並協調各個實體類，完成一個流程。

2.三、業務邏輯層職責及相關爭議

2.3.一、數據的格式化

關於數據的格式化應該放在業務層進行仍是表示層進行一直存在爭議。我我的的意見是這樣的：

業務層送給表示層的數據應該具有如下要求。1）返回的數據應該完成了全部必要的業務處理和業務計算。例如，若返回訂單信息讓表示層展現，會有個必要的數據——訂單總額。這個數據須要首先用各個訂單項的單價乘以數量，而後加和。那麼，這個數據應該在業務層完成計算直接返回，總之不該讓表示層進行任何業務處理和計算操做。2）一次性返回全部須要的數據，避免表示層再一個Action裏調用屢次業務。 打個比方，例如訂單中有個「客戶姓名」，這個數據不保存在訂單表中，而是經過外鍵關聯的，那麼，業務層應該將「客戶姓名」一併取出返回給表示層。總之，避免表示層在一個Action裏屢次調用業務層。3）不攜帶任何格式信息，僅僅是結構良好的純淨數據，如DTO形式。 由於，數據如何展現，是表示層的職責，如何在業務層中返回了過多格式信息，就會形成表示層的修改困難。例如，我曾據說過所裏承接的一個實際項目，開始是使用B/S，當時他們的業務層返回的數據全都附帶了html代碼。後來，客戶嫌B/S響應不夠迅速（多是客戶公司的網絡條件很差），要求改爲C/S，當時全傻眼了，貌似幾乎修改了整個業務層。那個項目至關龐大，7個子系統，投入200人開發了1年多，想一想修改的難度吧。

2.3.二、數據合法性及完整性驗證

通常作系統，都避免不了數據驗證。上文曾經提到，完整性約束是業務邏輯的一部分。如此看來，數據驗證通常應該放在業務層。可是，實際狀況並不盡然。我的認爲數據驗證的方式，目前沒有統一標準，能夠根據須要放在表示層或業務層。可是，我我的不提倡在「表示層的服務端」放置過多完整性驗證。由於，表示層的職責應該僅僅是接收數據並傳遞給業務層，不該對數據是否合法負責。過多的數據驗證，不但令表示層代碼臃腫，並且使得表示層職責變得不明確。

能夠在「表示層的服務端」放置一些簡單的驗證，如空值驗證，兩次輸入密碼是否一致等，但業務關係緊密的驗證，最好放在業務層。甚至有些驗證只能在業務層驗證，如「當前用戶名不能與已有用戶名重複」，這種驗證須要訪問持久化數據，須要由業務層完成。

這裏之因此強調「表示層的服務端」，是由於通常在B/S系統中，都會在JavaScript里加入一些基本的數據驗證，如空值檢查，格式正則匹配等。這主要是爲了減輕服務器負擔，將大多數顯然包含不合法數據的請求拒絕掉，而不發給服務端驗證。固然，由於可能會出現JS被屏蔽或黑客惡意攻擊行爲，因此，全部驗證不論JS中是否驗證過，服務端（多是表示層的服務端部分或業務層）必定要再進行驗證。

2.3.三、CRUD

CRUD，即常說的增刪改查操做。關於CRUD是不是業務層的職責，一直也是爭議不斷。由於目前並無權威的定義，因此這裏我斗膽說一下我對這個問題的見解。還請你們批判性閱讀。

一說到「增刪改查」，你們必定會以爲這理所固然是數據訪問層的職責。我認爲這個理解是對的，可是隻對了一半！之因此這麼說，是由於「增刪改查」有兩個層次含義。

第一個層次，是數據訪問層次上的。在這個層次上，「增刪改查」只是單純的數據庫操做，「增刪改查」能夠理解爲「插入一條記錄，刪除一條記錄，更新一條記錄的信息，獲取一條或多條記錄」四個操做，其意義和着眼點徹底是數據訪問層面上的，不帶有任何業務成分和業務知覺。這個層面上的CRUD應該屬於數據訪問層的職責。

第二個層次，是業務邏輯層次上的。在這個層次上，「增刪改查」是業務領域內實體的變化以及一系列相關反應，「增刪改查」能夠理解爲「領域內新增一個業務實體，領域內去掉一個業務實體，領域內一個業務實體更新了信息，獲得領域內一個或多個業務實體的信息」。

二者最大的不一樣，是業務層面上的增刪改查每每不是單純的增長減小，還包括實體變化後相關的業務流程。下面舉個例子：

「添加一個新的訂單」——這是一條典型的「增」操做。在數據訪問層面上，它的意義是「在表示訂單的數據表裏增長一條記錄」；而在業務邏輯層面上，它的意義除了「領域內多了一個訂單實體」外，還可能包括「根據業務規則判斷是不是重複下單，根據金額對下訂單客戶的等級作相應提高、發送Email和短信通知客戶等」。能夠看到，業務層面上的「增」可能不只是簡單封裝一個簡單的插入記錄，可能還要去作其餘數據訪問——提高用戶等級，以及作一些非CRUD的業務操做 ——發送短信通知。

在許多稍微複雜的系統中，業務每每不只僅是封裝了一條數據訪問操做，而是還有不少如計算等業務處理，一個業務操做期間可能要屢次使用數據訪問操做。退一步說，即便某個業務僅僅封裝了一條數據訪問操做，其意義和層面也是不一樣的，在數據訪問層面，僅僅是多了一條記錄，而業務邏輯層面，是領域內多了一個業務實體。也許其本質上都是往數據庫插入一條記錄，但人類的抽象思惟能夠將之在不一樣層面上區分，這也是人類思惟層面的一種抽象能力的表現。例如，咱們知道太陽升起不過是地球自轉使得從背陰面轉到了向陽面，但當人們看日出時，不多有人會說「看！咱們從背陰面轉到向陽面了！」，咱們會說「看！日出！」，這就是同一事物的不一樣層次表現。

2.3.四、存儲過程

也許是性能上的誘惑，許多人喜歡在數據庫系統中寫很複雜的存儲過程。這樣，許多業務操做就被寫到存儲過程當中去了。我我的建議，除非對性能要求極高，不然最好仍是不要用存儲過程實現業務。例如，在通常的系統中，某個業務操做可能須要1秒，而是用了存儲過程只用0.1秒，看上去存儲過程將效率提升了10倍。但對大多數用戶來講，1秒和0.1秒的差異並不大，可是這樣作的話，業務會變得十分不容易維護。因此，我我的以爲，除非十分必要，仍是不要用存儲過程實現業務。

三、業務邏輯的架構模式及實現

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.一、Transction Script

3.1.一、概述

Transction Script（如下簡稱TS）是一種面向過程的業務邏輯組織方式。這裏首先要強調一點，這裏的Transction一詞與數據庫系統中表示「事務」的 Transction沒有任何聯繫。TS是將領域中的業務分解爲一個個業務過程，每一個過程實現一項業務功能，具體到程序中，一個業務過程每每映射到一個方法。TS是徹底面向過程的業務組織模式，適合應用於業務邏輯較簡單的場合。

應該說，咱們見到的絕大多數系統都是以TS組織業務的。例如PetShop及Oxite等經典示例。有時爲了方便維護，開發者會將同一領域實體相關的業務方法集中到一個類中，這裏雖然用到了領域實體和類的概念，但和麪向對象沒有任何關係，徹底是面向過程的。

當使用TS時，能夠不須要數據訪問層，而是將數據操做執行代碼（如執行SQL或存儲過程的代碼）直接嵌入在業務方法中，有時爲了複用性和維護性能夠編寫一個helper類封裝數據庫的操做。固然這並非說TS不能配合數據訪問層使用，但因爲應用TS的場合通常業務很是簡單，若是配合Repository或 ORM使用，業務邏輯層每每就會變得很是「瘦」，看起來僅僅是對數據訪問層的封裝。通常在須要支持多數據庫的場合，要配合Repository和 Abstract Factory使用。

TS的示意圖以下所示：

圖3-一、 Transcation Script架構示意

能夠看到，在TS中，業務層並無面向對象的東西。也許會用到類，但類只是組織業務方法的模塊，每一個模塊中有一個個業務方法，每一個業務方法完成一個業務流程，徹底按面向過程結構組織。

3.1.二、分析

• 何時能夠用TS？

應該說，若是具有如下條件之一 ，你能夠考慮TS：

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

2）工期很緊，須要儘可能壓縮設計的時間，儘快投入編碼

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

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

• TS的優勢？

1）設計階段投入較小，啓動耗費低。由於TS較容易掌握，使用起點低，因此使用TS的初期投入較少

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

• TS的缺點？

1）容易形成代碼冗餘。由於各個業務自行組織流程，因此減小了複用的機會，可能產生重複性代碼

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

3.二、Table Module

3.2.一、概述

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

通常當業務相對簡單且業務基本集中在CRUD操做時，能夠考慮TM。使用TM意味着使用數據驅動設計。一般本身實現一套庫-表結構操做對象的庫是難度比較大的，因此通常選用TM時，所使用的平臺應該包括這麼一套庫。如.NET平臺上的ADO.net就內置了豐富的庫-表操做，DataSet，DataTable，DataAdapter等在TM架構的實現中能夠起到很是方便的做用。

使用TM後，通常不須要再配合Reponsitory或ORM，由於此時的業務層也是面向過程和麪向關係型結構的，無須映射。

TM的示意圖以下：

圖3-二、Table Module架構示意  

 

在使用TM後，業務代碼中每每有各類對象對應數據庫中的庫、表、記錄、字段等元素，並提供相似關係數據庫的操做。

3.2.二、分析

• 何時能夠用TM？

若是同時 具有如下條件，你能夠考慮TM：

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

2）整個開發的指導思想是數據驅動

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

• TM的優勢？

1）相似關係數據庫的數據操做方式很是直觀，使得設計和編寫數據操做功能的代碼簡單高效

• TM的缺點？

1）TM須要徹底的數據驅動，從業務到UI傳遞、存放數據都要以表結構形式，形成必定程度上的不靈活

2）當業務並不是CRUD集中型操做，特別是領域模型和數據庫表模型差別較大時，使用TM組織業務的難度很是大

3.三、Active Record

3.3.一、概述

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

使用AR時，通常最好有相應框架支持，不然徹底手工實現AR有點麻煩。像Castle框架中就有AR功能，Linq to sql也有AR的意思。使用AR後，通常不須要再單獨使用數據訪問層。

AR的組織架構以下圖：

  

圖3-三、Active Record架構示意

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

3.3.二、分析

• 何時能夠用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.四、Domain Model

3.4.一、概述

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

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

下面看一下DM的架構示意圖：

  

圖3-四、Domain Model架構示意

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

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

第一，DM中的業務對象是純業務對象，不含數據訪問操做。這個能夠和AR中的業務對象對比一下。也就是說，DM中的業務對象是純業務對象，它們只關注與業務的實現。

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

第三，DM須要業務部分「持久化無知」。所謂持久化無知，指業務部分只需執行業務功能，而沒必要關係持久化。在使用DM時，必須設計一套ORM機制（注意這裏用到了「機制」一詞，而不是「框架」或「庫」），使得在業務系統運行時，自動在必要的時候執行數據持久化操做。這也是爲何上圖數據源和業務層間的箭頭是虛線的關係。

上文曾說過，DM要最大程度模擬現實狀況。而現實世界和軟件世界最大的區別就是現實世界是「內存無限大、永不停機的」，能夠把現實世界當作在一個無限大內存裏永不中止運行的程序。而軟件世界不一樣，它的內存有限制，咱們不能將全部對象都放在內存，並且一旦掉電，它就會中止運行，正因如此，咱們才須要持久化機制去配合DM模擬現實世界。爲了讓業務更接近現實，它必須對持久化過程毫無感受。而一套持久化機制默默爲其營造了一個好似內存無限大、永不停機的環境，所以DM才得以發揮威力。

第四，DM每每須要Services Layer的配合。由於DM內部僅有一個個業務對象，它們互相調用，並無提供一個友好的接口與UI交互，因此在使用DM時，每每在其上對各類UI須要的服務進行封裝（回顧一下Facade模式），造成一個Services Layer，以方便與UI交互。

3.4.二、分析

• 何時能夠用DM？

若是同時 具有如下條件，你能夠考慮DM：

1）系統業務極爲複雜

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

3）項目經費和時間充足

4）貫徹領域驅動設計

• DM的優勢？

1）徹底的OO思想運用，將使你享受到OO的全部優點

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

• DM的缺點？

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

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

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

3.五、各類架構模式的比較及選擇

相信看過上文內容後，各位必定對各類業務組織模式及其特色、優劣、應用場景有了清晰地認識，若是我在這裏再喋喋不休討論各類模式的比較及如何選擇，不免有侮辱各位智商之嫌O(∩_∩)O~，因此這裏我只給你們呈現一幅決策網絡圖，以期起到一個梳理和概括總結的做用。

圖3-五、業務架構模式決策網絡

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

四、結束語

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

另外，因爲本文僅僅是綜述性文章，不能具名業務邏輯的各個方面，在深度上也基本是淺嘗輒止。所以，若但願深刻理解業務邏輯，能夠看到相關經典書籍及文獻。