其實各種架構(gòu)模式并不是憑空出現(xiàn)的，是你寫代碼到達一定功底的時候自然出現(xiàn)的結(jié)果。走的彎路多了，就會主動去思考該如何將代碼組織的更好，更符合業(yè)務需求與架構(gòu)標準。

　　Fowler的《企業(yè)應用架構(gòu)模式》 (Patterns of Enterprise Application Architecture)就是這樣一本書，里面詳細敘述了企業(yè)級開發(fā)中常用的架構(gòu)模式。對于業(yè)務邏輯層，常見的有四種：

　　注：

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

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

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

　　再來看表模式與活動記錄。這其實是兩種換湯不換藥的方式。比事務腳本進步的方面在于將數(shù)據(jù)庫的表對象單獨獨立了出來，一個類對應一張數(shù)據(jù)庫表。獨立的方式有所區(qū)別：表模式是一個DataTable對應一張表， 然后附上其CRUD，活動記錄是一個Model實體類對應一張數(shù)據(jù)庫表，然后附上其CRUD。這種方式對于單表操作，簡單業(yè)務邏輯可能比較方便，但涉及到復雜業(yè)務，多表關(guān)聯(lián)的時候，由于單表對應的類處理不了，多數(shù)情況下仍然需要重新建立一個類，其命名類似于XXXManage,XXXHandler的方式，來專門處理這類復雜邏輯，多表操作的問題，其方法一般與UML的用例相關(guān)。一旦業(yè)務足夠復雜，項目規(guī)模足夠大，這種方式仍然會引發(fā)復用性不夠，針對復雜邏輯適應性極差等問題。

　　以上三種方式有個相同點，就是始終以數(shù)據(jù)為中心。數(shù)據(jù)庫的表結(jié)構(gòu)，在程序邏輯中占有非常重要的位置，業(yè)務邏輯的處理，始終圍繞著處理表數(shù)據(jù)來展開，業(yè)務代碼編寫人員，始終要比較明白數(shù)據(jù)庫的設(shè)計方式。 一個類的狀態(tài)部分(屬性)與行為部分(方法)始終分離，還談不上真正的面向?qū)ο缶幊獭?br>

　　最后來看領(lǐng)域模型，這種方式是解決大業(yè)務量，復雜邏輯的解決方式。在這里完全拋棄首先建庫的思想，緊緊圍繞客戶需求來進行分析，提煉業(yè)務主體，明確交互方式，構(gòu)建出一個個有血有肉的對象。最后按照客戶需求或程序需要將數(shù)據(jù)或狀態(tài)保存到數(shù)據(jù)庫中。

　　有個比較形象的比喻：在面向過程的處理當中，程序員就是上帝，你掌管理一切的生老病死，從頁面的展示到業(yè)務的處理到數(shù)據(jù)的存儲。在對向?qū)ο蟮奶幚懋斨校阒皇钦{(diào)度者，你只負責在合適的時間用合適的對象去處理合適的業(yè)務。

　　參考的文章：

　　系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應用架構(gòu)-業(yè)務邏輯層

　　走向ASP.NET架構(gòu)設(shè)計—第四章—業(yè)務層分層架構(gòu)

　　九種不夠面向?qū)ο蟮膶ο?/a>

　　關(guān)于ActiveRecord、領(lǐng)域模型以及iBatis的種種想法

　　DAO-持久層-領(lǐng)域?qū)ο?貧血模型

　　ActiveRecord 模型