1.3  Fowler的企業(yè)設(shè)計(jì)模式

Martin Fowler的著作Patterns of Enterprise Application Architecture是有關(guān)如何構(gòu)建企業(yè)級(jí)應(yīng)用程序的最佳實(shí)踐和模式的參考書。與GoF設(shè)計(jì)模式著作一樣，經(jīng)驗(yàn)豐富的開(kāi)發(fā)者毫無(wú)疑問(wèn)已經(jīng)遵循該書中歸納的許多設(shè)計(jì)模式。但Fowler著作的價(jià)值在于，在對(duì)這些模式進(jìn)行分類時(shí)使用一種公用語(yǔ)言來(lái)描述模式。該書分為兩部分：前半部分討論n層應(yīng)用程序和數(shù)據(jù)訪問(wèn)、中間件以及表示層的組織；后半部分是與GoF模式著作相似的模式參考，但本書的實(shí)現(xiàn)更加具體。

本書將討論Fowler設(shè)計(jì)模式的ASP.NET實(shí)現(xiàn)。下面將介紹本書剩余部分將要涉及的模式。

1.3.1  分層

第3章講解了在企業(yè)ASP.NET應(yīng)用程序分層時(shí)可供自由采用的選項(xiàng)。我們將了解傳統(tǒng)的Web表單代碼隱藏模型帶來(lái)的問(wèn)題以及如何使用傳統(tǒng)的分層方法將表示、業(yè)務(wù)邏輯及數(shù)據(jù)訪問(wèn)等關(guān)注點(diǎn)分離開(kāi)來(lái)。

1.3.2  領(lǐng)域邏輯模式

第4章介紹了組織業(yè)務(wù)邏輯的3種常見(jiàn)方法：Transaction Script(事務(wù)腳本)、Active Record(活動(dòng)記錄)及Domain Model(領(lǐng)域模型)。

1. Transaction Script

Transaction Script模式按照線性的、過(guò)程式方法來(lái)組織業(yè)務(wù)邏輯。它將細(xì)粒度的業(yè)務(wù)用例映射為細(xì)粒度的方法。

2. Active Record

Active Record模式按照一種能夠緊密匹配底層數(shù)據(jù)結(jié)構(gòu)的方式來(lái)組織業(yè)務(wù)邏輯，即表中表示數(shù)據(jù)行的對(duì)象。

3. Domain Model

Domain Model模式是對(duì)現(xiàn)實(shí)領(lǐng)域?qū)ο蟮某橄蟆Ｍ瑫r(shí)對(duì)數(shù)據(jù)和行為建模。對(duì)象之間可以存在與真實(shí)領(lǐng)域相匹配的復(fù)雜關(guān)系。

我們將展示如何在ASP.NET中使用這些模式，以及何時(shí)適合選擇某一種模式而非其他模式。

1.3.3  對(duì)象關(guān)系映射

在第7章中，將注意力轉(zhuǎn)向如何將業(yè)務(wù)實(shí)體的狀態(tài)持久化，以及如何從數(shù)據(jù)存儲(chǔ)中檢索它們。介紹以下幾種支持持久化的基礎(chǔ)設(shè)施代碼所需的企業(yè)模式。

1. Unit of Work

Unit of Work(工作單元)模式用來(lái)維護(hù)一個(gè)由已經(jīng)經(jīng)過(guò)業(yè)務(wù)事務(wù)修改(添加、刪除或更新)的業(yè)務(wù)對(duì)象構(gòu)成的列表。然后，Unit of Work模式負(fù)責(zé)將這些發(fā)生變化的對(duì)象的持久化工作協(xié)調(diào)成為一個(gè)原子動(dòng)作。如果出現(xiàn)問(wèn)題，整個(gè)事務(wù)就會(huì)回滾。

2. Repository

Repository(資源庫(kù))模式大體上用于對(duì)象的邏輯集合，它們更為人知的名字叫做聚合(aggregate)。它充當(dāng)業(yè)務(wù)實(shí)體的內(nèi)存集合或倉(cāng)庫(kù)，完全將底層數(shù)據(jù)基礎(chǔ)設(shè)施抽象出來(lái)。

3. Data Mapper

Data Mapper(數(shù)據(jù)映射器)模式用來(lái)從原始數(shù)據(jù)中提取信息以生成對(duì)象，以及將業(yè)務(wù)對(duì)象中的信息轉(zhuǎn)換到數(shù)據(jù)庫(kù)。業(yè)務(wù)對(duì)象和數(shù)據(jù)庫(kù)彼此互不了解。

4. Identity Map

Identity Map(標(biāo)識(shí)映射)模式監(jiān)視每一個(gè)從數(shù)據(jù)庫(kù)中加載的對(duì)象，確保所有對(duì)象只加載一次。當(dāng)后面請(qǐng)求該對(duì)象時(shí)，在從數(shù)據(jù)庫(kù)檢索之前先檢查標(biāo)志映射。

5. Lazy Loading

Lazy Loading(惰性加載或延遲加載)模式將獲取資源的過(guò)程推遲到真正需要用到該資源的時(shí)候。如果想象一個(gè)攜帶著通訊錄的Customer對(duì)象，那么可以從數(shù)據(jù)庫(kù)中提取這個(gè)顧客對(duì)象，但保留通訊錄的生成操作，直到真正需要用到該通訊錄時(shí)才生成。這可以實(shí)現(xiàn)按需加載通訊錄，從而避免在從來(lái)不需要用到該地址數(shù)據(jù)時(shí)訪問(wèn)數(shù)據(jù)庫(kù)。

6. Query Object

Query Object(查詢對(duì)象)模式是GoF的Interpreter(解釋器)設(shè)計(jì)模式的一種實(shí)現(xiàn)。查詢對(duì)象充當(dāng)一種從底層數(shù)據(jù)庫(kù)中抽象出來(lái)的面向?qū)ο蟛樵儯玫氖菍傩院皖?，而不是真正的表和列。通常，還需要使用一個(gè)翻譯器對(duì)象來(lái)生成用于查詢數(shù)據(jù)庫(kù)的原生SQL語(yǔ)句。