商務邏輯架構模式(事務指令碼，表模組，活動記錄，領域模型)

　　其實各種架構模式並不是憑空出現的，是你寫代碼到達一定功底的時候自然出現的結果。走的彎路多了，就會主動去思考該如何將程式碼群組織的更好，更符合業務需求與架構標準。

　　Fowler的《公司專屬應用程式架構模式》 (Patterns of Enterprise Application Architecture)就是這樣一本書，裡面詳細敘述了企業級開發中常用的架構模式。對於商務邏輯層，常見的有四種：

事務指令碼，表模組，活動記錄，領域模型。見圖：

 

　　註：

　　1.我在這裡畫了兩層：UI與BL，其實如果更極端一些，事務指令碼的CRUD，表模式的XXXManage與活動記錄的XXXHandler與UI層是可以合并的。

　　2.表模式的XXXManage與活動記錄的XXXHandler是同意詞，兩種不同的表達方式而以。

　　先來看事務指令碼，這是一種最面向過程的組織方式，上層UI需要什麼操作，下層就對應的寫出處理方式。一個方式從UI直接操作到DB，好處是上手快，方便書寫，壞處嘛，複用性不夠，針對複雜邏輯適應性極差

　　再來看錶模式與活動記錄。這其實是兩種換湯不換藥的方式。比事務指令碼進步的方面在於將資料庫的表對象單獨獨立了出來，一個類對應一張資料庫表。獨立的方式有所區別：表模式是一個DataTable對應一張表， 然後附上其CRUD，活動記錄是一個Model實體類對應一張資料庫表，然後附上其CRUD。這種方式對於單表操作，簡單商務邏輯可能比較方便，但涉及到複雜業務，多表關聯的時候，由於單表對應的類處理不了，多數情況下仍然需要重建立立一個類，其命名類似於XXXManage,XXXHandler的方式，來專門處理這類複雜邏輯，多表操作的問題，其方法一般與UML的用例相關。一旦業務足夠複雜，項目規模足夠大，這種方式仍然會引發複用性不夠，針對複雜邏輯適應性極差等問題。

　　以上三種方式有個相同點，就是始終以資料為中心。資料庫的表結構，在程式邏輯中佔有非常重要的位置，商務邏輯的處理，始終圍繞著處理表資料來展開，業務代碼編寫人員，始終要比較明白資料庫的設計方式。 一個類的狀態部分(屬性)與行為部分(方法)始終分離，還談不上真正的物件導向編程。

　　最後來看領域模型，這種方式是解決大業務量，複雜邏輯的解決方式。在這裡完全拋棄首先建庫的思想，緊緊圍繞客戶需求來進行分析，提煉業務主體，明確互動方式，構建出一個個有血有肉的對象。最後按照客戶需求或程式需要將資料或狀態儲存到資料庫中。

　　有個比較形象的比喻：在面向過程的處理當中，程式員就是上帝，你掌管理一切的生老病死，從頁面的展示到業務的處理到資料的儲存。在對向對象的處理當中，你只是調度者，你只負責在合適的時間用合適的對象去處理合適的業務。

 

　　參考的文章：

　　系統架構師-基礎到公司專屬應用程式架構-商務邏輯層

　　走向ASP.NET架構設計—第四章—業務層分層架構

　　九種不夠物件導向的對象

　　關於ActiveRecord、領域模型以及iBatis的種種想法

　　DAO-持久層-領域對象-貧血模型

　　ActiveRecord 模型