[Page]

第1章　企業(yè)解決方案的構(gòu)建模式
  
  版本 1.1.0
  
  “我們發(fā)現(xiàn)，目前正常工作的復(fù)雜系統(tǒng)總是從以前正常工作的簡單系統(tǒng)演變而來的……從頭開始設(shè)計(jì)的復(fù)雜系統(tǒng)總是不能正常工作，也無法通過修補(bǔ)來使其正常工作。您必須從正常工作的簡單系統(tǒng)開始。”— John Gall 發(fā)表于 Systemantics: How Systems Really Work and How They Fail
  
  企業(yè)級(jí)業(yè)務(wù)解決方案是公司實(shí)現(xiàn)其業(yè)務(wù)的賭注，它們通常極其復(fù)雜，而且性能必須不負(fù)眾望。它們不僅必須具有高可用性和伸縮性以應(yīng)對(duì)不可預(yù)知的使用，而且還必須具有適應(yīng)性和預(yù)見性以適應(yīng)快速變化的業(yè)務(wù)要求。
  
  最佳解決方案是那些由一組更小的、簡單的、能夠可靠且有效地解決簡單問題的機(jī)制組成的解決方案。在構(gòu)建更大、更復(fù)雜的系統(tǒng)過程中，將這些簡單的機(jī)制組合在一起，從而形成更大的系統(tǒng)。
  
  對(duì)這些簡單機(jī)制的認(rèn)識(shí)來之不易。它通常存在于有經(jīng)驗(yàn)的開發(fā)人員和體系結(jié)構(gòu)設(shè)計(jì)者的頭腦中，并且是他們潛意識(shí)中自然帶到項(xiàng)目中的重要知識(shí)。
  
  本指南旨在獲取經(jīng)驗(yàn)豐富的開發(fā)人員的知識(shí)，并以模式目錄的形式呈現(xiàn)這些知識(shí)。每種模式都包含一個(gè)簡單的、經(jīng)過證實(shí)可以有效解決小問題的機(jī)制。雖然您可以單獨(dú)理解和運(yùn)用每種模式，但您還會(huì)經(jīng)常組合這些模式來構(gòu)建復(fù)雜的系統(tǒng)。
  
  模式對(duì)于開發(fā)人員和體系結(jié)構(gòu)設(shè)計(jì)者非常有用，因?yàn)樗鼈儯?
  
  記錄能夠正常工作的簡單機(jī)制。
  為開發(fā)人員和體系結(jié)構(gòu)設(shè)計(jì)者提供通用的詞匯和分類法。
  允許以模式組合的方式簡明扼要地描述方案。
  允許重復(fù)使用體系結(jié)構(gòu)、設(shè)計(jì)和實(shí)現(xiàn)決策。
  本章將介紹模式的概念，并解釋模式如何記錄簡單的和經(jīng)過證實(shí)的機(jī)制，最后展示模式集合如何為開發(fā)人員和體系結(jié)構(gòu)設(shè)計(jì)者提供公用語言。為了闡明這些概念，本章運(yùn)用了真實(shí)開發(fā)情形中實(shí)際模式的簡化版本。
  
  模式可以記錄簡單機(jī)制
  
  模式描述給定上下文中反復(fù)出現(xiàn)的問題，并基于一組指導(dǎo)性影響因素來建議解決方案。解決方案通常是一種簡單的機(jī)制，是為了解決模式中所標(biāo)示出的問題而一起工作的兩個(gè)或多個(gè)類、對(duì)象、服務(wù)、進(jìn)程、線程、組件或節(jié)點(diǎn)之間的協(xié)作。
  
  
  --------------------------------------------------------------------------------
  注意：在這些模式中描述的基礎(chǔ)機(jī)制雖然概念上很簡單，但實(shí)際上，它們的實(shí)現(xiàn)卻相當(dāng)復(fù)雜。實(shí)現(xiàn)時(shí)，必須具備一定的技能和判斷能力，才能對(duì)常規(guī)模式進(jìn)行取舍，以適應(yīng)具體的環(huán)境。另外，出于介紹的目的，本章所提到的模式已進(jìn)行了高度的精簡，后面幾章將更詳細(xì)地介紹各種實(shí)際模式。
  --------------------------------------------------------------------------------
  
  考慮下例：
  
  您正在構(gòu)建一個(gè)報(bào)價(jià)應(yīng)用程序，其中有一個(gè)類負(fù)責(zé)管理系統(tǒng)中的所有報(bào)價(jià)。很重要的一點(diǎn)是，所有報(bào)價(jià)都應(yīng)與該類的一個(gè)（而且只與一個(gè)）實(shí)例進(jìn)行交互。如何構(gòu)造您的設(shè)計(jì)，以便從該應(yīng)用程序中只能訪問該類的一個(gè)實(shí)例？
  
  解決該問題最簡單的方案就是創(chuàng)建一個(gè)具有私用構(gòu)造函數(shù)的 QuoteManager 類，以便任何其他類都不能實(shí)例化它。此類包含 QuoteManager 的一個(gè)靜態(tài)實(shí)例，并使用名為 GetInstance() 的靜態(tài)方法返回。此代碼大體如下所示：
  
  public class QuoteManager
  {
   //注意：僅適用于單線程應(yīng)用程序
   private static QuoteManager _Instance = null;
   private QuoteManager() {}
   public static QuoteManager GetInstance()
   {
   if (_Instance==null)
   {
   _Instance = new QuoteManager ();
   }
   return _Instance;
   }
  
   //... QuoteManager 提供的函數(shù)
  }
  
  您可能已經(jīng)像其他許多開發(fā)人員那樣通過類似的方式解決過類似的問題。實(shí)際上，注意反復(fù)出現(xiàn)的問題并尋求解決方案的模式作者已經(jīng)屢次發(fā)現(xiàn)了這種實(shí)現(xiàn)，提取出了通用解決方案并將這種問題-解決方案對(duì)稱為 Singleton 模式 [Gamma95]。
  問題-解決方案對(duì)模式
  
  請(qǐng)注意，Singleton 模式不涉及 Quote 或 QuoteManager 類。但其外觀有點(diǎn)類似于下面的簡化示例。 
   
   
   
  圖 1: 簡化的 Singleton 模式
  
  通過將圖 1 中簡化的模式示例與 QuoteManager 源代碼進(jìn)行比較，闡明了模式（通用問題-解決方案對(duì)）和模式應(yīng)用程序（針對(duì)非常具體的問題的具體解決方案）之間的區(qū)別。模式級(jí)別的解決方案是多個(gè)類之間簡單但極其順暢的協(xié)作。模式中的通用協(xié)作專門適用于 QuoteManager 類，提供了用來控制報(bào)價(jià)應(yīng)用程序中實(shí)例化的機(jī)制。顯然，您可以稍微修改一下某種模式以滿足局部的特定要求，所以同一種模式可以應(yīng)用于無數(shù)個(gè)應(yīng)用程序。
  
  所編寫的模式提供了一種記錄簡單且經(jīng)過證實(shí)的機(jī)制的有效方法。模式是以特定格式編寫的，這一點(diǎn)對(duì)于裝載復(fù)雜思想的容器非常有用。這些模式在被記載和起名之前，就早已存在于開發(fā)人員的大腦及其代碼中。有時(shí)，模式作者從實(shí)際的實(shí)現(xiàn)中發(fā)現(xiàn)了這些模式，并對(duì)它們進(jìn)行推廣，以便應(yīng)用于其他應(yīng)用程序。
  
  雖然模式作者通常在這些通用模式中提供了實(shí)現(xiàn)代碼示例，但是一定要了解實(shí)現(xiàn)這些模式還有許多其他正確的方法。其中的關(guān)鍵在于了解模式中的指導(dǎo)原則，并根據(jù)自己的具體情形自定義它。例如，如果您熟悉 Singleton 模式，則可能已注意到代碼示例是基于 [Gamma95] 實(shí)現(xiàn)的。這里使用該實(shí)現(xiàn)的原因在于它是最常見的示例，而且在介紹模式時(shí)所需的說明最少。但是，針對(duì) C# 語言優(yōu)化的 Singleton 實(shí)現(xiàn)則會(huì)有較大的差異；雖然這兩種實(shí)現(xiàn)存在很大的區(qū)別，但是兩者均正確。
  
  位于不同級(jí)別的模式
  
  模式存在于多個(gè)不同的抽象級(jí)別中?？紤]另一個(gè)示例（這次所處的抽象級(jí)別比源代碼要高一級(jí)）：
  
  您要設(shè)計(jì)一個(gè)基于 Web 的報(bào)價(jià)應(yīng)用程序，其中包含大量業(yè)務(wù)和表示邏輯，這些邏輯反過來依賴大量平臺(tái)軟件組件來提供適當(dāng)?shù)膱?zhí)行環(huán)境。如何在高級(jí)別組織系統(tǒng)以使其在具有靈活、松耦合性的同時(shí)仍具有高內(nèi)聚性？
  
  此問題的解決方案之一涉及到按一系列層來組織系統(tǒng)，每層包含大致位于同一抽象級(jí)別的元素。隨后，確定每一層中的依賴性，并確定采用嚴(yán)格還是寬松的分層策略。接著，決定是打算創(chuàng)建自定義的分層方案，還是采用以前由其他人記錄的分層方案。在本例中，假設(shè)您決定使用眾所周知的分層策略：表示、業(yè)務(wù)邏輯和數(shù)據(jù)訪問各占一層。圖 2 顯示了分層方案的可能外觀。 
   
   
  圖2. 報(bào)價(jià)應(yīng)用程序的層
  
  如果您總是按這種方式設(shè)計(jì)系統(tǒng)，說明您已經(jīng)在不依賴于任何廣義模式的情況下使用該模式。即便如此，您還可能因多種原因而希望了解支撐這種設(shè)計(jì)方法的模式。您可能迫切想知道為何經(jīng)常以這種方式構(gòu)建系統(tǒng)，或者可能在尋找更理想的方法來解決此模式不能完全解決的問題。無論是哪種情況，都值得研究一下這里所使用的模式和機(jī)制。
  
  使用層作為高級(jí)別組織方法是 Layers（層）模式 [Buschmann96] 中描述的完善模式。圖 3 顯示了該模式的簡化版本。 
   
   
  圖3. 簡化的 Layers 模式
  
  這個(gè)簡單的應(yīng)用程序組織策略有助于解決軟件開發(fā)中面臨的兩個(gè)挑戰(zhàn)：依存關(guān)系的管理和對(duì)可交換組件的需求。如果在構(gòu)建應(yīng)用程序時(shí)沒有一個(gè)考慮周全的依存關(guān)系管理策略，會(huì)導(dǎo)致組件易損壞且不牢靠，從而導(dǎo)致對(duì)它們進(jìn)行維護(hù)、擴(kuò)展和替代時(shí)存在較大的困難，而且成本較高。
  
  Layers 模式中的工作機(jī)制比 Singleton 中的工作機(jī)制更精細(xì)。對(duì)于 Layers，首次協(xié)作是在設(shè)計(jì)時(shí)發(fā)生在類之間，這是由于分層組織將對(duì)更改源代碼所帶來的影響局部化，從而防止所做的更改貫穿到整個(gè)系統(tǒng)。第二次協(xié)作發(fā)生在運(yùn)行時(shí)：某層中相對(duì)獨(dú)立的組件變得可與其他組件交換，再一次使系統(tǒng)其余部分不受影響。
  
  盡管 Layers 模式的通用性足以應(yīng)用于諸如網(wǎng)絡(luò)協(xié)議、平臺(tái)軟件和虛擬機(jī)之類的領(lǐng)域，但是它無法解決企業(yè)類業(yè)務(wù)解決方案中存在的某些特定問題。例如，除通過分解來管理復(fù)雜性（由 Layers 解決的基本問題）外，業(yè)務(wù)解決方案開發(fā)人員還需要進(jìn)行適當(dāng)組織，以便有效地重復(fù)使用業(yè)務(wù)邏輯并保留與昂貴資源（如數(shù)據(jù)庫）的重要連接。解決此問題的方法之一就是使用 Three-Layered Application（三層應(yīng)用程序）模式。圖 4 顯示了該模式的簡化說明。 
   
   
   
  圖4. 簡化的 Three-Layered Application
  
  同樣，在模式 (Three-Layered Application) 和模式應(yīng)用程序（報(bào)價(jià)應(yīng)用程序分層模型）之間存在區(qū)別。模式是有關(guān)應(yīng)用程序組織主題的通用問題-解決方案對(duì)，而模式應(yīng)用程序是通過創(chuàng)建具體的層（每層都滿足非常具體的需求）來解決非常具體的問題。
  
  簡單優(yōu)化
  
  請(qǐng)注意，Three-Layered Application 實(shí)際上是在 Layers 的基礎(chǔ)上進(jìn)行的簡單優(yōu)化；在 Layers 中確定的上下文、影響因素和解決方案仍適用于 Three-Layered Application，但反之不行。也就是說，Layers 模式約束著 Three-Layered Application 模式，而 Three-Layered Application 模式優(yōu)化了 Layers 模式。這種模式關(guān)系對(duì)于復(fù)雜性管理非常有用。當(dāng)您理解某種模式之后，肯定只是了解了初始模式與其優(yōu)化模式之間的遞增區(qū)別。另一個(gè)示例（這次涉及 Web Service 領(lǐng)域）應(yīng)該有助于闡明優(yōu)化的概念：
  
  您為某個(gè)發(fā)展迅速的成功企業(yè)構(gòu)建了一個(gè)報(bào)價(jià)應(yīng)用程序?，F(xiàn)在，您希望通過向業(yè)務(wù)合作伙伴公開自己的報(bào)價(jià)引擎并將其他合作伙伴服務(wù)（如配送）集成到該報(bào)價(jià)應(yīng)用程序中來擴(kuò)展該應(yīng)用程序。您將如何構(gòu)造自己的業(yè)務(wù)應(yīng)用程序以提供和享受服務(wù)？
  
  此問題的解決方案之一是通過將其他與服務(wù)相關(guān)的職責(zé)添加到每一層中來擴(kuò)展 Three-Layered Application。在業(yè)務(wù)層添加了以下職責(zé)：通過 Service Interfaces（服務(wù)接口）向客戶應(yīng)用程序提供一組簡化的操作。數(shù)據(jù)訪問層的職責(zé)拓寬到了數(shù)據(jù)庫和主機(jī)集成之外，以包括與其他服務(wù)提供者的通信。將數(shù)據(jù)訪問層中的這個(gè)附加功能封裝到服務(wù)接口組件中，這些組件負(fù)責(zé)連接到服務(wù)（同步和異步）、管理服務(wù)的基本會(huì)話狀態(tài)并向業(yè)務(wù)流程組件通知與服務(wù)相關(guān)的重大事件。
  
  Three-Layered Services Application（三層服務(wù)應(yīng)用程序）（圖 5）記錄了該問題-解決方案對(duì)。 
   
   
   
  圖5. 簡化的 Three-Layered Services Application
  
  將 Three-Layered Services Application 模式應(yīng)用于報(bào)價(jià)應(yīng)用程序示例將形成如下模型。 
   
  圖6. 應(yīng)用于報(bào)價(jià)應(yīng)用程序的 Three-Layered Services Application
  
  請(qǐng)注意這些模式之間的關(guān)系（請(qǐng)參閱圖 7）。Layers 引進(jìn)了一個(gè)用來組織軟件應(yīng)用程序的基本策略。Three-Layered Application 優(yōu)化了此概念，并將它限制在需要重復(fù)使用業(yè)務(wù)邏輯、靈活部署和高效使用連接的業(yè)務(wù)系統(tǒng)的范圍內(nèi)。Three-Layered Services Application 又在 Three-Layered Application 的基礎(chǔ)上進(jìn)行了優(yōu)化，并對(duì)設(shè)計(jì)進(jìn)行了擴(kuò)展，以便在提供和使用其來源千差萬別的數(shù)據(jù)和邏輯時(shí)，將這些數(shù)據(jù)和邏輯處理為粒狀元素。 
   
  圖7. 相關(guān)模式的優(yōu)
  
  向特定層中添加其他類型的組件并不是管理這種日益增長的復(fù)雜性的唯一方法。正如復(fù)雜性所證實(shí)的那樣，設(shè)計(jì)人員通常在應(yīng)用程序中創(chuàng)建其他層來承擔(dān)該職責(zé)。例如，一些設(shè)計(jì)人員將服務(wù)接口移到一個(gè)單獨(dú)的層中。而另外一些設(shè)計(jì)人員將業(yè)務(wù)層分隔成域?qū)雍蛻?yīng)用程序?qū)?。在任何情況下，您有時(shí)可能會(huì)看到某些設(shè)計(jì)人員在使用此模式來滿足復(fù)雜要求時(shí)，有時(shí)會(huì)將這三層擴(kuò)展到四層、五層或者甚至六層。與之相反，Layers 模式也用在相對(duì)簡單的客戶端-服務(wù)器應(yīng)用程序中（標(biāo)準(zhǔn)情況是兩層應(yīng)用程序）。
  
  當(dāng)組合在一起時(shí)，Layers 的這些變體組成了模式群集（請(qǐng)參閱圖 8），該模式群集直觀地表示出了應(yīng)用程序分層的常見方法。此上下文中涉及的群集僅表示以邏輯方式組合某組相似的模式。群集的概念對(duì)于下列操作非常有用：擴(kuò)展模式視圖以包含整個(gè)解決方案；標(biāo)識(shí)出處理解決方案范圍內(nèi)類似問題的模式群集。第 2 章“組織模式”將更詳細(xì)地討論群集。 
   
   
  圖8. 模式群集
  
  常見詞匯
  
  在考慮 Singleton、Layers、Three-Layered Application 和 Layered Services Application 模式時(shí)，您可能已注意到模式還提供了用來溝通軟件體系結(jié)構(gòu)和設(shè)計(jì)思想的強(qiáng)大詞匯。了解模式不僅能夠就模式所涉及的知識(shí)和體驗(yàn)進(jìn)行溝通，而且還提供了一個(gè)唯一的、便于記憶的名稱，以便充當(dāng)評(píng)估和描述軟件設(shè)計(jì)選項(xiàng)時(shí)的速記法。
  
  例如，在設(shè)計(jì)應(yīng)用程序時(shí)，開發(fā)人員可能會(huì)說：“我認(rèn)為定價(jià)引擎應(yīng)當(dāng)作為 Singleton 實(shí)現(xiàn)并通過 Service Interface 公開。”如果另一個(gè)開發(fā)人員了解這些模式，那么他或她將非常清楚所討論的設(shè)計(jì)的含義。如果開發(fā)人員不理解這些模式，那么他或她可以在目錄中查看它們并學(xué)習(xí)相應(yīng)的機(jī)制，甚至有機(jī)會(huì)一起學(xué)習(xí)其他模式。
  
  模式有一種自然分類法。如果您了解足夠多的模式及其相互關(guān)系，則可以開始了解位于不同抽象級(jí)別的、多組經(jīng)過排序的組和類別。例如，Singleton 模式示例位于比 Layers 模式低的抽象級(jí)別，但是，Layers 模式包含一組以不同方式進(jìn)行過優(yōu)化的相關(guān)模式。第 2 章進(jìn)一步擴(kuò)展和優(yōu)化了此分類法。
  
  隨著時(shí)間的推移，開發(fā)人員不斷發(fā)現(xiàn)和描述新模式，從而拓寬了開發(fā)人員在該領(lǐng)域的知識(shí)體系。另外，當(dāng)您開始了解模式和模式之間的關(guān)系時(shí)，就可以采用模式術(shù)語來描述整個(gè)解決方案。
  
  解決方案簡述
  
  在本指南中，術(shù)語“解決方案”有兩種截然不同的含義：其一是表示模式本身的一部分（如某上下文中包含的問題-解決方案對(duì)）；其二是表示業(yè)務(wù)解決方案。在使用“業(yè)務(wù)解決方案”這一術(shù)語時(shí)，它是指專用來滿足一組特定的功能和操作業(yè)務(wù)要求的軟件密集型系統(tǒng)。軟件密集型系統(tǒng)意味著您不只是關(guān)心軟件，而且還必須將該軟件部署到硬件處理節(jié)點(diǎn)以提供整體的技術(shù)解決方案。而且，所考慮的軟件不僅包括自定義開發(fā)的軟件，而且包括購買的軟件基礎(chǔ)結(jié)構(gòu)和平臺(tái)組件，所有這些都被集成在了一起。
  
  小結(jié)
  
  本章介紹了模式概念，解釋了模式如何記錄簡單且經(jīng)過證實(shí)的機(jī)制，并闡明了模式如何為開發(fā)人員和體系結(jié)構(gòu)設(shè)計(jì)者提供公用語言。第 2 章將解釋如何組織關(guān)于模式的思想以及如何使用模式來簡述整個(gè)解決方案。

[Page]

  第2章　組織模式
  
  版本: 1.1.0
  
  “于是，每種模式既依賴于它所包含的更小的模式，又依賴于包含它的更大的模式?！薄?Christopher Alexander 發(fā)表于The Timeless Way of Building
  
  一項(xiàng)技術(shù)領(lǐng)域的革新通常會(huì)刺激另一個(gè)領(lǐng)域的突破。雷達(dá)技術(shù)促進(jìn)了微波爐這一烹調(diào)設(shè)備的誕生。Internet 本身最初被設(shè)計(jì)為一種具有預(yù)防單點(diǎn)攻擊能力的軍事通信網(wǎng)絡(luò)，而現(xiàn)在已轉(zhuǎn)變?yōu)槭澜缟献畲蟮闹R(shí)儲(chǔ)存庫。同樣，模式最初應(yīng)用于建筑和城鎮(zhèn)體系結(jié)構(gòu)，但很快就被軟件開發(fā)社區(qū)采用，并作為一種描述復(fù)雜軟件系統(tǒng)的方法。
  
  現(xiàn)在，每天都在涌現(xiàn)出大量與軟件相關(guān)的模式。大量模式引發(fā)了一系列新的挑戰(zhàn)。開發(fā)人員如何標(biāo)識(shí)那些與手頭的任務(wù)最相關(guān)的模式？模式集合是否足以描述整個(gè)解決方案？
  
  本章通過示范如何完成下列任務(wù)而回答了其中的一些問題：
  
  標(biāo)識(shí)模式之間的關(guān)系。
  將模式組合成群集。
  標(biāo)識(shí)位于不同抽象級(jí)別的模式。
  將模式應(yīng)用于一個(gè)解決方案的多個(gè)方面。
  將模式組織為框架。
  使用模式來簡述解決方案。
  模式的模式
  
  面向?qū)ο蟮木幊躺鐓^(qū)之所以如此重視模式，是由于模式能夠描述關(guān)系。面向?qū)ο缶幊痰幕驹厥穷?。但是，如果拋開與構(gòu)成解決方案的其他類的關(guān)系不談，單個(gè)類就沒有太大意義。每種模式通常都描述一組類，并強(qiáng)調(diào)它們之間的關(guān)系和交互。因此，模式將大量類轉(zhuǎn)換成更易于管理的模式集合。
  
  由于在一般應(yīng)用程序中，可用模式的數(shù)量很容易超出類的數(shù)量，因此您可能突然發(fā)現(xiàn)自己位于模式的海洋。那么，怎樣才能了解所有這些模式的含義呢？重申一遍，項(xiàng)目之間的關(guān)系似乎是問題的關(guān)鍵。顯而易見，一些模式與其他模式緊密相關(guān)。例如，有些模式是對(duì)另一些模式的優(yōu)化。Three-Tiered Distribution （三級(jí)分布）是Tiered Distribution（分級(jí)分布）概念的一個(gè)具體應(yīng)用。Observer （觀察器）通常用于實(shí)現(xiàn) Model-View-Controller （模型-視圖-控制器）模式的一部分。Page Controller （頁面控制器）更加詳細(xì)地描述了 Model-View-Controller 的控制器部分。在 ASP.NET 中實(shí)現(xiàn) Page Controller 是使用 Microsoft® ASP.NET 對(duì) Page Controller 模式的實(shí)現(xiàn)。
  
  要開始按照關(guān)系組織模式，請(qǐng)將一組模式設(shè)想成小圓（請(qǐng)參閱圖 1）： 
   
   
  圖 1. 一組模式
  
  如果您在每對(duì)具有某種關(guān)系的模式之間繪制一條直線，則可以看到如下所示的圖片： 
   
   
  圖 2. 用直線表示的模式關(guān)系
  
  帶點(diǎn)隨機(jī)性的小圓的集合形成了連在一起的模式網(wǎng)。當(dāng)您查看某種模式時(shí)，可以立即標(biāo)識(shí)出與其緊密相關(guān)的模式并進(jìn)行審閱。您還可以標(biāo)識(shí)緊密相關(guān)的模式的“鄰居”，并查看它們與其他更遠(yuǎn)的模式存在什么樣的關(guān)系。
  
  模式群集
  
  使用圖表來表示模式之間的關(guān)系有助于從一種模式轉(zhuǎn)移到一組相關(guān)的模式。但是，它仍不能告訴您該從何處著手。如果您正在構(gòu)建一個(gè) Web 應(yīng)用程序，應(yīng)該首先學(xué)習(xí)Model-View-Controller 模式，還是應(yīng)該先查看 Page Cache （頁面緩存）？是否還應(yīng)該查看Broker （代理程序）？
  
  模式群集是一組涉及特定主題區(qū)域的模式。例如，您可以從 Web 表示群集開始查找與創(chuàng)建 Web 應(yīng)用程序前端相關(guān)的模式。同樣，分布式系統(tǒng)群集包含有助于與遠(yuǎn)程對(duì)象通信的模式。如果將模式集合劃分為群集，則可以同時(shí)檢查一組模式。雖然模式圖也顯示出了兩種模式是相關(guān)的，但群集匯總能夠更詳細(xì)地描述如何通過組合不同的模式來構(gòu)建實(shí)際的解決方案。每個(gè)群集都為讀者提供了指導(dǎo)教程，便于其了解該群集中的所有模式。受 Christopher Alexander 的城鎮(zhèn)與構(gòu)造建筑物世界的啟發(fā)，您可以將群集與城市鄰近地區(qū)進(jìn)行類比。為了將這種類比關(guān)系向前推進(jìn)一點(diǎn)，可以將群集匯總視為當(dāng)?shù)芈糜尉痔峁┑慕煌糜螆D。 
   
  圖 3. 模式群集
  
  最初發(fā)布的“使用 Microsoft .NET 的企業(yè)解決方案模式 (ESP)”標(biāo)識(shí)出了表 1 中所示的五個(gè)群集。
  
  表 1：企業(yè)解決方案模式群集
  
  群集 問題
  Web 表示 如何創(chuàng)建動(dòng)態(tài) Web 應(yīng)用程序？
  部署 如何將應(yīng)用程序劃分為層，然后將它們部署到多級(jí)硬件基礎(chǔ)結(jié)構(gòu)上？
  分布式系統(tǒng) 如何與駐留在不同進(jìn)程或不同計(jì)算機(jī)中的對(duì)象進(jìn)行通信？
  性能和可靠性 如何創(chuàng)建一個(gè)能夠滿足至關(guān)重要的操作要求的系統(tǒng)基礎(chǔ)結(jié)構(gòu)？
  服務(wù) 如何訪問由其他應(yīng)用程序提供的服務(wù)？如何將您的應(yīng)用程序功能作為服務(wù)呈現(xiàn)給其他應(yīng)用程序？
  
  
  第 3 章到第 7 章將詳述這些群集。
  
  不同的抽象級(jí)別
  
  將模式劃分成群集可使其更便于管理。如果您要構(gòu)建 Web 應(yīng)用程序的前端，請(qǐng)從 Web 表示群集著手，然后參加快速教程并查看有哪些其他模式與該群集相關(guān)。但請(qǐng)牢記一點(diǎn)，不同的人可能對(duì)構(gòu)建 Web 應(yīng)用程序的不同方面感興趣，這取決于他們所扮演的角色或項(xiàng)目所處的階段。開發(fā)人員可能對(duì)在 Microsoft .NET Framework 上以最高的效率實(shí)現(xiàn)Page Controller 模式最感興趣，而體系結(jié)構(gòu)設(shè)計(jì)者可能對(duì)決定是使用三級(jí)還是四級(jí)應(yīng)用程序體系結(jié)構(gòu)更感興趣。
  
  因此，抽象級(jí)別最適合對(duì)模式進(jìn)行分類，以便不同的用戶組可以查找與其感興趣的領(lǐng)域最匹配的模式。從一般到更具體來劃分模式有助于確定應(yīng)當(dāng)首先考慮哪些模式。在考慮使用 ASP.NET 實(shí)現(xiàn) Page Cache 模式中描述的復(fù)雜的 ASP.NET 緩存指令之前，您可能應(yīng)該先考慮應(yīng)用程序應(yīng)該有多少級(jí)。
  
  對(duì)模式進(jìn)行分類的方法之一就是將模式圖分成如圖 4 所示的三個(gè)級(jí)別。 
   
  圖 4. 抽象級(jí)別
  
  這種劃分方法與某些講述軟件模式的最具影響力的圖書中使用的術(shù)語基本一致。
  
  體系結(jié)構(gòu)模式
  
  “體系結(jié)構(gòu)模式表示軟件系統(tǒng)的基礎(chǔ)結(jié)構(gòu)組織架構(gòu)。它提供一組預(yù)定義的子系統(tǒng)、指定它們的職責(zé)并包括用來組織它們之間關(guān)系的規(guī)則和準(zhǔn)則。”[Buschmann96]
  
  ESP 遵循 Buschmann 等對(duì)結(jié)構(gòu)模式的定義。這些模式描述如何在最高級(jí)別構(gòu)造應(yīng)用程序。例如，Layered Application （分層應(yīng)用程序）模式就是一種體系結(jié)構(gòu)模式。
  
  設(shè)計(jì)模式
  
  “設(shè)計(jì)模式提供一種用來優(yōu)化軟件系統(tǒng)的子系統(tǒng)或組件或者相互之間的關(guān)系的架構(gòu)。它描述通信組件中經(jīng)常重復(fù)使用的、能夠解決特定上下文中的一般設(shè)計(jì)問題的結(jié)構(gòu)。” [Gamma95]
  
  設(shè)計(jì)模式提供下一級(jí)別的優(yōu)化，如 Gamma 等的創(chuàng)作性作品中所述。許多圖標(biāo)性模式（如 Model-View-Controller 或Singleton）都位于這一層。
  
  實(shí)現(xiàn)模式
  
  模式社區(qū)將更詳細(xì)的、特定于編程語言的模式稱為慣用語。此定義適合于軟件模式。但是，本指南的適用范圍并不局限于軟件，它同樣適用于軟件密集型系統(tǒng)，包括將軟件部署到硬件處理節(jié)點(diǎn)以提供整體的業(yè)務(wù)解決方案。因此，ESP 對(duì) Pattern-Oriented Software Architecture (POSA) [Buschmann96] 中給出的慣用語的定義進(jìn)行了修改，以反映更廣泛的范圍并將這些模式重新標(biāo)記為實(shí)現(xiàn)模式：
  
  實(shí)現(xiàn)模式是特定于某個(gè)特殊平臺(tái)的更低一級(jí)的模式。實(shí)現(xiàn)模式描述如何使用給定平臺(tái)的功能實(shí)現(xiàn)組件的某些方面或它們之間的關(guān)系。
  
  ESP 實(shí)現(xiàn)模式闡明了如何使用 .NET Framework 實(shí)現(xiàn)設(shè)計(jì)概念。在某些情況下，該框架中已經(jīng)包含了大量工作，這更便于開發(fā)人員執(zhí)行任務(wù)。
  
  
  --------------------------------------------------------------------------------
  注意：雖然 POSA [Buschmann96] 將慣用語定義為了模式，而且 The Timeless Way of Building [Alexander79] 在 Alexander 的原始模式作品中包括實(shí)現(xiàn)模式，但在模式社區(qū)的一些成員之間，仍就實(shí)現(xiàn)模式是否為真正的模式存在爭議。無論如何對(duì)它們進(jìn)行分類，在考慮模式時(shí)它們都非常有用，因此將其包含在了本指南中。
  --------------------------------------------------------------------------------
  
  如果將模式集合劃分為三個(gè)抽象級(jí)別，則更便于不同的用戶組標(biāo)識(shí)與其感興趣且擅長的領(lǐng)域相關(guān)的模式。生成的模型從高級(jí)別組織流出，途經(jīng)對(duì)子系統(tǒng)和組件進(jìn)行的不斷優(yōu)化，最后使用平臺(tái)特定的技術(shù)實(shí)現(xiàn)了這些模式。
  
  視點(diǎn)
  
  雖然抽象級(jí)別有助于解決不同用戶組的問題，但是它們不能反映出軟件解決方案比代碼組件包含更多內(nèi)容這一事實(shí)。構(gòu)建企業(yè)解決方案的整體視圖包括自定義開發(fā)的軟件、平臺(tái)軟件、硬件基礎(chǔ)結(jié)構(gòu)以及軟件到硬件的部署。由于這些區(qū)域互相之間存在非常明顯的區(qū)別，所以有必要將這些模式與該命名相對(duì)應(yīng)。
  
  請(qǐng)牢記，這四個(gè)區(qū)域描述的是同一個(gè)解決方案的不同視點(diǎn)。因此，與優(yōu)化級(jí)別不同的是，這些視點(diǎn)不描述層次結(jié)構(gòu)，而只是提供看待同一事情的四種不同方法。您可以將這些視點(diǎn)比喻為不同類型的地圖。一個(gè)地區(qū)的某張地圖可能描繪的是交通網(wǎng)（如公路和高速公路），而同一地區(qū)的另一張地圖顯示的是地形。還可能有另一張地圖用來顯示州界和縣界。每張地圖都有其各自的詞匯。例如，地形圖中的直線表示海拔，而交通圖中的直線表示街道。然而，所有地圖描述的都是同一個(gè)主題：特定的地理區(qū)域。
  
  每個(gè)視點(diǎn)本身還可以強(qiáng)調(diào)不同的抽象級(jí)別。因此，ESP 將下列視點(diǎn)描繪為模式圖中的垂直薄片：數(shù)據(jù)庫、應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)。應(yīng)用程序視點(diǎn)和基礎(chǔ)結(jié)構(gòu)視點(diǎn)之間通常有一個(gè)很大的間隙。概念、抽象和技能集都存在足夠大的區(qū)別，這樣可以保證在應(yīng)用程序視點(diǎn)和基礎(chǔ)結(jié)構(gòu)視點(diǎn)之間插入一個(gè)緩沖區(qū)，以便幫助在二者之間建立連接。此視點(diǎn)被稱作部署視點(diǎn)。
  
  此推理過程將產(chǎn)生如表 2 所示的四個(gè)視點(diǎn)。
  
  表 2：企業(yè)解決方案模式視點(diǎn)
  
  視點(diǎn) 描述
  數(shù)據(jù)庫 數(shù)據(jù)庫視圖描述應(yīng)用程序的永久層。此視圖包括諸如邏輯和物理架構(gòu)、數(shù)據(jù)庫表、關(guān)系和事務(wù)處理等內(nèi)容。
  應(yīng)用程序 應(yīng)用程序視圖強(qiáng)調(diào)解決方案的可執(zhí)行方面。它包括諸如域模型、類圖表、程序集和進(jìn)程等內(nèi)容。
  部署 部署視圖將應(yīng)用程序關(guān)注點(diǎn)明確映射到基礎(chǔ)結(jié)構(gòu)關(guān)注點(diǎn)（如將進(jìn)程映射到處理器）。
  基礎(chǔ)結(jié)構(gòu) 基礎(chǔ)結(jié)構(gòu)視圖包含運(yùn)行解決方案所必需的所有硬件和網(wǎng)絡(luò)設(shè)備。
  
  
  圖5 將這些視點(diǎn)以豎線形式覆蓋到模式圖和抽象級(jí)別上。 
   
  圖 5. 添加視點(diǎn)
  
  為簡單起見，圖 5 未顯示群集的邊界。但是，群集、抽象級(jí)別和視點(diǎn)是平行存在的。它們代表訪問同一組模式的不同方法。
  
  模式框架
  
  垂直軸上的三個(gè)優(yōu)化級(jí)別以及水平軸上的四個(gè)視點(diǎn)這一組合形成一個(gè)網(wǎng)格狀的模式組織圖。圖 6 顯示了這種名為模式框架的排列。 
   
  圖 6. 模式框架
  
  模式框架作為參考點(diǎn)和導(dǎo)航助手隨每個(gè)單獨(dú)的模式描述提供。
  
  約束
  
  模式框架按照各種有意義的子類別組織模式集合。例如，現(xiàn)在可以將重點(diǎn)放在數(shù)據(jù)庫視圖的設(shè)計(jì)模式或應(yīng)用程序視圖的實(shí)現(xiàn)模式。
  
  但是，軟件采用了各種各樣的形式。目前，軟件運(yùn)行在以下幾類系統(tǒng)上：嵌入式系統(tǒng)（如起搏器和電信設(shè)備）、實(shí)時(shí)系統(tǒng)（如防鎖死剎車系統(tǒng)）或數(shù)據(jù)倉庫系統(tǒng)（旨在分析消費(fèi)者的購買行為）。如果嘗試處理與各種形式的所有軟件解決方案相關(guān)的模式，將快速擴(kuò)展任何單一的圖書或模式儲(chǔ)存庫的作用范圍。因此，ESP 將模式限制在企業(yè)業(yè)務(wù)解決方案上。因?yàn)?ESP 這一術(shù)語有些模糊，所以它只是標(biāo)識(shí)模式圖中一小組特定的頂級(jí)體系結(jié)構(gòu)模式或根模式。該集合中的所有其他模式都遵循下列約束：
  
  聯(lián)機(jī)事務(wù)處理 (OLTP)
  面向?qū)ο?
  分層應(yīng)用程序
  分級(jí)分布系統(tǒng)
  OLTP 系統(tǒng)是用來管理事務(wù)處理的數(shù)據(jù)庫子系統(tǒng)。這些子系統(tǒng)確保每個(gè)事務(wù)的原子性、一致性、獨(dú)立性及持久性（所謂的 ACID 特性）。實(shí)際上，這些應(yīng)用程序通常處理一個(gè)或多個(gè)用來維護(hù)企業(yè)業(yè)務(wù)狀態(tài)的關(guān)系數(shù)據(jù)庫。換句話說，這些應(yīng)用程序是用來跟蹤客戶、訂單、帳戶等的數(shù)據(jù)庫。通過將 OLTP 標(biāo)識(shí)為模式框架中的頂級(jí)約束，ESP 排除了不支持事務(wù)處理的聯(lián)機(jī)分析處理 (OLAP) 系統(tǒng)或簡單平面文件系統(tǒng)。OLTP 的“聯(lián)機(jī)”特性意味著一旦業(yè)務(wù)狀態(tài)發(fā)生變化，這些系統(tǒng)將立即讀取或更新數(shù)據(jù)庫，而不考慮脫機(jī)批處理。
  
  從應(yīng)用程序視點(diǎn)考慮，模式框架受兩種模式的約束：Object-Oriented Application（面向?qū)ο蟮膽?yīng)用程序）和Layered Application.（分層應(yīng)用程序）。大多數(shù)（如果不是全部）應(yīng)用程序視點(diǎn)模式都依賴面向?qū)ο蟮母拍睿ㄈ绶庋b、多形性和繼承）來成功解決影響它們的問題。因此，模式框架只處理面向?qū)ο蟮膽?yīng)用程序，并不特意處理程序上的應(yīng)用程序。
  
  引人注目的企業(yè)應(yīng)用程序通常包括大量對(duì)象和服務(wù)，這些對(duì)象和服務(wù)必須通過協(xié)作來提供對(duì)業(yè)務(wù)存在一定價(jià)值的東西。為了管理這些協(xié)作，必須存在某個(gè)高級(jí)別系統(tǒng)組織。大多數(shù)企業(yè)級(jí)系統(tǒng)都使用分層方法來管理這種復(fù)雜性。因此，模式框架只處理設(shè)計(jì)為一系列層的應(yīng)用程序，并特意排除沒有或者具有較少內(nèi)部結(jié)構(gòu)的單一應(yīng)用程序。
  
  從基礎(chǔ)結(jié)構(gòu)視點(diǎn)，該模型被限制在支持跨多個(gè)按級(jí)排列的服務(wù)器分布應(yīng)用程序的硬件基礎(chǔ)結(jié)構(gòu)上。這種分級(jí)方法通常用于企業(yè)應(yīng)用程序，這是由于它的啟動(dòng)成本相對(duì)較低，而且它支持?jǐn)U展策略（可通過向基礎(chǔ)結(jié)構(gòu)中添加開銷不大的服務(wù)器以遞增方式增加容量）。從模型中排除的是基于以下操作的解決方案：將應(yīng)用程序部署到單個(gè)主機(jī)或大型多處理器計(jì)算機(jī)中。
  
  部署視點(diǎn)關(guān)注以下問題：縫合應(yīng)用程序視點(diǎn)和基礎(chǔ)結(jié)構(gòu)視點(diǎn)之間的間隙。因此，它本身沒有任何約束，但運(yùn)行時(shí)受應(yīng)用程序視點(diǎn)和基礎(chǔ)結(jié)構(gòu)視點(diǎn)所設(shè)置的約束的限制。換句話說，最高級(jí)別的部署模式涉及的是將分層應(yīng)用程序映射到分級(jí)分布基礎(chǔ)結(jié)構(gòu)中，而不對(duì)它本身施加任何其他約束。
  
  如果將這四個(gè)高級(jí)別約束或根約束視為一個(gè)組，將有助于縮小在本指南其余部分中討論的模式的范圍。圖 7 顯示了位于模塊框架頂部的根約束。 
   
  圖 7. 模式框架的根約束
  
  通過縮小模式框架的范圍，可以更詳細(xì)地闡述具體模式以及這些模式之間的關(guān)系。
  
  Pattlets
  
  使用根約束可以將模式的數(shù)量減少到易于管理的數(shù)量級(jí)。然而，詳述該網(wǎng)格中的所有模式可能需要大量的工作。如果分開開發(fā)所有模式，然后發(fā)布“最終模式指南”，將無法獲得許多由模式社區(qū)實(shí)現(xiàn)的價(jià)值。隨著大家對(duì)模式的理解的進(jìn)步，模式也需要發(fā)展。模式不是由單個(gè)作者創(chuàng)建的，而是軟件開發(fā)社區(qū)實(shí)際應(yīng)用的結(jié)晶。在認(rèn)識(shí)到模式的發(fā)展本質(zhì)之后，本指南的作者已經(jīng)發(fā)布了本文中包括的模式的子集，目的在于聽取大家的意見并著手組建一個(gè)社區(qū)。
  
  但是，如果將模式延緩到稍后一些，會(huì)在模式圖中留下漏洞，這可能會(huì)導(dǎo)致相關(guān)的模式突然斷開連接。為了使模式圖中的關(guān)系保持完整，本指南提供了第一版本中未包括的模式（即 Pattlet）。Pattlet 是尚未詳細(xì)記載的實(shí)際模式。Pattlet 描述問題的解決方案，但是不包含對(duì)可能影響解決方案的上下文、問題或因素的詳細(xì)說明。
  
  Pattlet 這一概念對(duì)于參考以前的模式作品也非常有用。在過去的十年中，模式社區(qū)一直發(fā)現(xiàn)并記錄軟件模式。如果試圖重復(fù)這些工作，將是非常愚蠢的。而要求讀者購買幾本其他圖書來了解這些模式的上下文的想法也很不明智。因此，本指南在參考有關(guān)模式的現(xiàn)有圖書中所描述的模式時(shí)，包括了一個(gè) Pattlet 模式。Pattlet 還包括對(duì)原始作品的參考，以供那些希望更詳細(xì)查看完整模式的讀者參考。
  
  有關(guān)所有 Pattlet 的詳細(xì)列表，請(qǐng)參閱附錄 A。
  
  解決方案的模式語言
  
  受到約束的模式框架及其所包含的模式提供了足夠多的數(shù)據(jù)點(diǎn)，以便開始使用模式來描述整個(gè)解決方案。實(shí)際上，第 1 章中的報(bào)價(jià)示例可以用模式術(shù)語來描述。回憶一下，其要求中指定了一個(gè)基于 Web 的報(bào)價(jià)應(yīng)用程序。描述解決方案體系結(jié)構(gòu)的用戶可能會(huì)做如下表述：
  
  首先讓我們?cè)诔橄蟮捏w系結(jié)構(gòu)級(jí)別看一下這個(gè)報(bào)價(jià)應(yīng)用程序。從應(yīng)用程序視點(diǎn)，報(bào)價(jià)應(yīng)用程序是面向?qū)ο蟮膽?yīng)用程序，它在邏輯上構(gòu)造成Three-Layered Services Application. （三層服務(wù)應(yīng)用程序）。從數(shù)據(jù)庫視點(diǎn)，應(yīng)用程序是基于 OLTP 處理模型的。從基礎(chǔ)結(jié)構(gòu)視點(diǎn)，硬件和網(wǎng)絡(luò)體系結(jié)構(gòu)是基于 Four-Tiered Distribution（四級(jí)分布）的，這要求 Web 服務(wù)器功能和應(yīng)用程序服務(wù)器功能具有不同的物理級(jí)。最后，從部署視點(diǎn)，小組已經(jīng)基于復(fù)雜的 Web 應(yīng)用程序創(chuàng)建了一個(gè)Deployment Plan （部署規(guī)劃），以便將組件映射到服務(wù)器。
  
  這從所有這四個(gè)視點(diǎn)向熟悉參考模式的讀者簡述了解決方案的體系結(jié)構(gòu)。繼續(xù)向下移動(dòng)一個(gè)抽象級(jí)別，可能會(huì)看到作者這樣描述系統(tǒng)設(shè)計(jì)：
  
  從應(yīng)用程序視點(diǎn)，讓我們分別考慮 Three-Layered Services Application（三層服務(wù)應(yīng)用程序）的每一層。
  
  表示層是圍繞基于Model-View-Controller (MVC) 的 Web 表示框架構(gòu)造的。盡管 MVC 將業(yè)務(wù)層和表示邏輯層分開了，但是每一頁都包含大量公共邏輯。為了消除這種冗余，我們使用Page Controller 來呈現(xiàn)公共頭和尾注信息并為用戶設(shè)置友好的顯示名稱。
  
  業(yè)務(wù)層包含客戶、報(bào)價(jià)、訂單、系列物品和庫存域?qū)ο?。由于開發(fā)速度是一個(gè)重要要求，因此這些域?qū)ο笫鞘褂?Table Module（表模塊）[Fowler03] 實(shí)現(xiàn)的。復(fù)雜的 Web 應(yīng)用程序 Deployment Model （部署模型）要求 Web 級(jí)和應(yīng)用程序級(jí)分開。因此，這兩級(jí)通過一個(gè)代理程序進(jìn)行通信。業(yè)務(wù)實(shí)體充當(dāng) Data Transfer Objects [Fowler03]，用于封裝在這兩級(jí)之間傳送的信息。
  
  數(shù)據(jù)層使用 Data Table Gateway [Fowler03] 來訪問 OLTP 數(shù)據(jù)庫子系統(tǒng)，并使用大量數(shù)據(jù)訪問組件來支持域?qū)ο蟮某志眯砸蟆?
  
  從基礎(chǔ)結(jié)構(gòu)視點(diǎn)：為了滿足業(yè)務(wù)的操作要求，我們通過添加Load-Balanced Cluster （負(fù)載平衡群集）和Failover Cluster（故障轉(zhuǎn)移群集）來基于基本的 Four-Tiered Distribution（四級(jí)分布）模型構(gòu)建。為了滿足高級(jí)別并發(fā)用戶的要求，我們?cè)?Web 級(jí)中添加了負(fù)載平衡功能。為了滿足可用性要求，我們?cè)跀?shù)據(jù)庫級(jí)中添加了群集。
  
  可以繼續(xù)描述位于同一抽象級(jí)別的數(shù)據(jù)和部署視點(diǎn)。為此，再向下移動(dòng)一個(gè)抽象級(jí)別，可能會(huì)看到作者這樣描述解決方案的實(shí)現(xiàn)：
  
  讓我們從應(yīng)用程序視點(diǎn)來查看解決方案。解決方案是使用 Microsoft .NET 技術(shù)構(gòu)建的。表示層基于 ASP.NET 中內(nèi)置的 Web 表示框架。ASP.NET 使用內(nèi)置的代碼隱藏頁功能來簡化 Model-View-Controller 的實(shí)現(xiàn)。我們使用 ASP.NET 中內(nèi)置的 Page Controller 機(jī)制來實(shí)現(xiàn)表示邏輯。業(yè)務(wù)層中的域?qū)ο笫?.NET 托管對(duì)象。因?yàn)楸硎緦雍蜆I(yè)務(wù)層部署在不同的級(jí)上，所以我們使用服務(wù)器激活對(duì)象通過 .NET Remoting 實(shí)現(xiàn) Broker。最后，數(shù)據(jù)層基于 .NET Framework 中的 ADO.NET 類來提供數(shù)據(jù)庫訪問。Table Modules（表模塊）和業(yè)務(wù)實(shí)體是使用 ADO.NET 的數(shù)據(jù)集組件構(gòu)造的。數(shù)據(jù)訪問組件的其余部分由 Microsoft Application Blocks for .NET 構(gòu)建塊提供。
  
  從基礎(chǔ)結(jié)構(gòu)視點(diǎn)：Microsoft SQL Server® 運(yùn)行在故障轉(zhuǎn)移群集中，用于 OLTP 數(shù)據(jù)庫子系統(tǒng)中。Microsoft 網(wǎng)絡(luò)負(fù)載平衡群集在 Web 服務(wù)器之間提供負(fù)載平衡。
  
  所有這些會(huì)話都經(jīng)常參考各種模式。最初，這可能有點(diǎn)讓人望而卻步，但當(dāng)您了解所使用的模式后，就會(huì)認(rèn)識(shí)到即使是一個(gè)簡短的描述也會(huì)讓您詳細(xì)了解系統(tǒng)是如何工作的。請(qǐng)注意，您不必翻閱大量文檔或逐步執(zhí)行無窮無盡的代碼行，即可對(duì)此有所了解。設(shè)想一下在不使用模式的情況下描述解決方案而需涉及到的工作，就不難知道模式所帶來的溝通好處。
  
  小結(jié)
  
  本章闡釋了模式如何在不影響細(xì)節(jié)的情況下提供可以高效描述復(fù)雜解決方案的詞匯。模式有效地構(gòu)成了一種新語言，體系結(jié)構(gòu)設(shè)計(jì)者和設(shè)計(jì)人員可以使用它們來交流其想法。
  
  由于在構(gòu)建企業(yè)解決方案時(shí)會(huì)涉及到大量模式，所以學(xué)習(xí)這個(gè)新語言似乎很難。本指南將各種模式組織成了更小、更緊密相關(guān)的模式集，這使您能夠根據(jù)自己的具體興趣或項(xiàng)目的階段，從使用一小組模式開始。
  
  本章介紹了四個(gè)有助于瀏覽模式的機(jī)制：
  
  關(guān)系。模式之間的關(guān)系有助于標(biāo)識(shí)與所用模式緊密相關(guān)的模式（如 Page Controller 強(qiáng)調(diào) Model-View-Controller 的控制器方面）。
  群集。群集將屬于共同主題范圍的模式組合在一起（如 Web 表示）。
  抽象級(jí)別。抽象級(jí)別使您能夠以一種與討論的詳細(xì)程度相一致的方式來描述概念（如體系結(jié)構(gòu)會(huì)話）。
  視點(diǎn)。視點(diǎn)有助于選擇與小組的特定角色相關(guān)的詞匯（如基礎(chǔ)結(jié)構(gòu)小組）。
  這些機(jī)制并不是要約束您的想法，而是旨在方便您查看復(fù)雜系統(tǒng)。實(shí)際上，當(dāng)您在角色、主題范圍和詳細(xì)程度之間切換時(shí)，您也將自然而然地在這些機(jī)制之間進(jìn)行了切換。

[Page]

第3章　Web 表示模式
  
  版本： 1.1.0
  
  “體系結(jié)構(gòu)設(shè)計(jì)者的第一個(gè)作品往往比較簡練和干凈。他知道自己并不了解正在進(jìn)行的工作，因此他小心謹(jǐn)慎地設(shè)計(jì)它。在他設(shè)計(jì)第一個(gè)作品時(shí)，會(huì)進(jìn)行多次修飾和潤色。這些會(huì)留到“下一次”使用……這第二個(gè)系統(tǒng)是他曾經(jīng)設(shè)計(jì)的最危險(xiǎn)的系統(tǒng)……一般趨勢(shì)是，在設(shè)計(jì)第二個(gè)系統(tǒng)時(shí)，將會(huì)使用在第一個(gè)作品中被小心擱置在一邊的所有思路和修飾，從而導(dǎo)致設(shè)計(jì)過了頭?！薄?Frederick P. Brooks, Jr. 發(fā)表于 1972 年的 The Mythical Man Month
  
  Web 上建立的第一個(gè)系統(tǒng)是簡單地鏈接在一起的靜態(tài) HTML 頁面，以便在分散的小組之間共享文檔。隨著用戶的使用量增加，可響應(yīng)用戶輸入的動(dòng)態(tài)網(wǎng)頁日益普遍。早期的動(dòng)態(tài)頁面一般是以通用網(wǎng)關(guān)接口 (CGI) 腳本的形式編寫的。這些 CGI 腳本不僅包含用來確定在響應(yīng)用戶輸入時(shí)應(yīng)當(dāng)顯示什么內(nèi)容的業(yè)務(wù)邏輯，而且還會(huì)生成表示 HTML。隨著對(duì)更復(fù)雜邏輯需求的增加，對(duì)更豐富、更生動(dòng)的表示形式的需求也隨之增加。這種增加了的復(fù)雜性給 CGI 編程模型帶來了挑戰(zhàn)。
  
  不久，基于頁面的開發(fā)手段（如 ASP 和 JSP）出現(xiàn)了。這些新方法允許開發(fā)人員將腳本直接嵌入到 HTML 面中，從而簡化了編程模型。當(dāng)這些嵌入的腳本應(yīng)用程序變得更復(fù)雜時(shí)，開發(fā)人員希望在頁面級(jí)別將業(yè)務(wù)邏輯與表示邏輯分開。為適應(yīng)這一要求，隨之出現(xiàn)了具有幫助器對(duì)象和代碼隱藏頁面策略的標(biāo)記庫。然后，又出現(xiàn)了提供動(dòng)態(tài)配置站點(diǎn)導(dǎo)航和命令調(diào)度程序的精細(xì)框架，但所有這一切都是以增加復(fù)雜性為代價(jià)的。假設(shè)現(xiàn)在有大量的 Web 表示可選方案，如何為您的應(yīng)用程序選擇適當(dāng)?shù)?Web 表示設(shè)計(jì)策略？
  
  復(fù)雜性和冗余
  
  不幸的是，沒有一個(gè)設(shè)計(jì)策略能夠適合所有情形。這是因?yàn)檐浖O(shè)計(jì)存在如下競爭性需求：消除過多的冗余和過度的復(fù)雜性。
  
  您可以從包含嵌入腳本的簡單頁面開始設(shè)計(jì)工作，但很快業(yè)務(wù)邏輯就會(huì)不斷重復(fù)出現(xiàn)在各個(gè)文件中，從而導(dǎo)致系統(tǒng)難以維護(hù)和擴(kuò)展。通過將該邏輯移到一組協(xié)作組件中，可以消除冗余，但是這樣做會(huì)增加解決方案的復(fù)雜性。另一方面，您的設(shè)計(jì)工作可以從設(shè)計(jì)用來提供標(biāo)記庫、動(dòng)態(tài)配置和命令調(diào)度程序的框架入手，可是這樣雖然能夠消除冗余代碼，但它會(huì)大大增加系統(tǒng)的復(fù)雜性，而這通常是不必要的。
  
  隨著復(fù)雜性的增加，您的設(shè)計(jì)意圖將會(huì)變得越來越模糊，使得其他開發(fā)人員更難理解您的系統(tǒng)；這還會(huì)導(dǎo)致系統(tǒng)更難維護(hù)和擴(kuò)展，從而增加總擁有成本。如果增加的復(fù)雜性是經(jīng)過認(rèn)真考慮并且是為了滿足當(dāng)前要求而保留的，則可能是值得的。而有的復(fù)雜性可能只是基于某一天會(huì)有額外需求這一可能性推測(cè)（而不是基于當(dāng)前的要求）而增加的。這會(huì)由于不必要的抽象而影響您的理解并妨礙您為今天提供正常工作的系統(tǒng)，從而使代碼混亂。
  
  因此，請(qǐng)重新考慮一下，應(yīng)該如何通盤考慮這些選項(xiàng)，才能獲得適合您的應(yīng)用程序的 Web 表示設(shè)計(jì)策略？
  
  首先，一定要了解關(guān)鍵的 Web 應(yīng)用程序設(shè)計(jì)問題、可能的解決方案和相關(guān)的利弊。本章為開發(fā)人員提供了沿著該思路的最佳起點(diǎn)。在該過程中，您將熟悉選項(xiàng)，評(píng)估利弊，然后選擇符合應(yīng)用程序要求的最簡單的解決方案。在復(fù)雜解決方案（支持將來可能發(fā)生變化的情形）和簡單解決方案（滿足目前的要求）之間做出抉擇之前，一定要深思熟慮。有時(shí)，適當(dāng)增加成本是可取的，而過多增加成本卻是不可取的。
  
  模式概述
  
  此模式群集直接從長期存在的 Model-View-Controller （模型-視圖-控制器）(MVC) 開始，自從將業(yè)務(wù)邏輯和表示邏輯分開以來，該模式已久經(jīng)時(shí)間的考驗(yàn)。雖然此模式不屬于新的 [Buschmann96]，但是該集合以一種簡化形式表示它，可以對(duì)其進(jìn)行定制以便構(gòu)建業(yè)務(wù)解決方案（而不是為富客戶端構(gòu)建用戶界面框架）。此模式最初是在設(shè)計(jì)級(jí)別編寫的，然后映射到了名為 在 ASP.NET 中實(shí)現(xiàn) Model-View-Controller 的平臺(tái)實(shí)現(xiàn)。圖 1 顯示 Web 表示模式群集。
  
  圖1 Web 表示模式群集
  
  在用 Microsoft® ASP.NET 實(shí)現(xiàn) MVC 時(shí)，是從一個(gè)簡單系統(tǒng)示例作為起點(diǎn)的：編寫在一個(gè)頁面上，而且將應(yīng)用程序邏輯嵌入表示元素中。隨著系統(tǒng)越來越復(fù)雜，使用了 ASP.NET 的代碼隱藏功能來將表示代碼（視圖）與模型控制器代碼分開。這始終能夠很好地工作，直至要求迫使您不得不考慮在沒有控制器的情況下重復(fù)使用模型代碼以避免應(yīng)用程序冗余。此時(shí)，需要?jiǎng)?chuàng)建獨(dú)立模型以抽象化業(yè)務(wù)邏輯，并使用代碼隱藏功能使模型適應(yīng)視圖代碼。然后，實(shí)現(xiàn)過程結(jié)束對(duì)該 MVC 方法測(cè)試含義的討論。
  
  迄今為止，使用 Model-View-Controller 模式時(shí)一直強(qiáng)調(diào)模型和視圖；控制器扮演相對(duì)次要的角色。實(shí)際上，在此模式中工作的控制器是 ASP.NET 中的隱式控制器。它負(fù)責(zé)感知用戶事件（請(qǐng)求和回發(fā)），并將這些事件寫入適當(dāng)?shù)南到y(tǒng)響應(yīng)（在本例中，指代碼隱藏頁中的事件）。
  
  在基于 Web 的動(dòng)態(tài)應(yīng)用程序中，在每次進(jìn)行頁請(qǐng)求時(shí)都會(huì)重復(fù)許多共同任務(wù)，如用戶驗(yàn)證、確認(rèn)、提取請(qǐng)求參數(shù)和查找與表示相關(guān)的數(shù)據(jù)庫。如果不對(duì)這些任務(wù)進(jìn)行管理，則會(huì)很快導(dǎo)致不必要的代碼重復(fù)。因?yàn)檫@些任務(wù)與感知用戶事件和確定正確的系統(tǒng)響應(yīng)完全相關(guān)，所以用來放置該行為的邏輯位置是在控制器中。
  
  功能更強(qiáng)大的控制
  
  此群集中的下一個(gè)模式是 Page Controller（頁面控制器），該模式是對(duì) Model-View-Controller 的優(yōu)化，并且能夠滿足下一個(gè)級(jí)別的復(fù)雜程度。此模式在頁面范圍中使用一個(gè)控制器，接受來自頁請(qǐng)求的輸入，針對(duì)模型調(diào)用請(qǐng)求的操作，然后確定要用作結(jié)果頁面的正確視圖。重復(fù)邏輯（如確認(rèn)）被移到了基本控制器類中。
  
  使用 ASP.NET 實(shí)現(xiàn) Page Controller 用常見的外觀示例闡述了 ASP.NET 內(nèi)置的頁面控制器的強(qiáng)大功能。實(shí)現(xiàn)過程還結(jié)合使用 Template Method（模板方法）[Gamma95] 模式與 Page Controller（頁面控制器）模式來定義操作中的算法框架，并將其中的一些步驟交由子類負(fù)責(zé)。
  
  隨著應(yīng)用程序越來越復(fù)雜，頁面控制器最終在基類中累積了大量邏輯，此問題通常通過加深頁面控制器的繼承層次結(jié)構(gòu)來解決。如果應(yīng)用程序十分復(fù)雜，這兩種因素都會(huì)導(dǎo)致代碼難以維護(hù)和擴(kuò)展。同樣，某些應(yīng)用程序需要?jiǎng)討B(tài)配置導(dǎo)航圖，這有可能跨越多個(gè)頁面控制器。達(dá)到這種復(fù)雜程度時(shí)，應(yīng)該考慮 Front Controller（前端控制器）。
  
  Front Controller, 是該目錄中的下一個(gè)模式，它也是對(duì) Model-View-Controller 的優(yōu)化。在前端控制器中，所有請(qǐng)求都通過單個(gè)（通常是兩部件）控制器來傳送。控制器的第一個(gè)部件是處理程序，第二個(gè)部件是 Commands（命令）[Gamma95] 的層次。命令本身是控制器的一部分，代表控制器觸發(fā)的特定操作。在執(zhí)行該操作之后，命令選擇要使用哪個(gè)視圖來呈現(xiàn)頁面。通常，構(gòu)建的此控制器框架使用配置文件將請(qǐng)求映射到操作，因此，它在構(gòu)建之后便于更改。當(dāng)然，其缺點(diǎn)在于這種設(shè)計(jì)固有的復(fù)雜程度。
  
  篩選器和緩存
  
  此群集中的最后兩種模式涉及到篩選器和緩存。
  
  Intercepting Filter （截取篩選器）為以下問題提供了解決方案：如何針對(duì) HTTP 請(qǐng)求實(shí)現(xiàn)常見的預(yù)處理和后處理。在 Intercepting Filter 中，最適合執(zhí)行非應(yīng)用程序特定的常見任務(wù)，如安全性檢查、日志記錄、壓縮、編碼和解碼。 Intercepting Filter 通常涉及到執(zhí)行某個(gè)特定任務(wù)。在針對(duì) HTTP 請(qǐng)求執(zhí)行多項(xiàng)任務(wù)時(shí)，多個(gè)篩選器會(huì)鏈接到一起。在 ASP.NET 中使用 HTTP 模塊實(shí)現(xiàn) Intercepting Filter 強(qiáng)調(diào)可在 ASP.NET 中方便地實(shí)現(xiàn)此模式。
  
  Page Cache （頁面緩存）通過保留創(chuàng)建成本極高的常用動(dòng)態(tài)網(wǎng)頁的副本來滿足 Web 應(yīng)用程序日益增加的可伸縮性和性能要求。在最初創(chuàng)建該頁面之后，會(huì)發(fā)送一份副本以便響應(yīng)以后的請(qǐng)求。Page Cache 還討論幾個(gè)關(guān)鍵的緩存設(shè)計(jì)因素，如緩存刷新、數(shù)據(jù)刷新和緩存粒度。在 ASP.NET 中使用絕對(duì)過期實(shí)現(xiàn) Page Cache 闡述了 ASP.NET 內(nèi)置的頁面緩存功能。
  
  Web 表示模式
  
  下表列出了 Web 表示模式群集中所包括的模式。這些模式的排列方式為較晚的模式構(gòu)建在較早的模式之上。這意味著發(fā)展方向是從更一般的模式（如 Model-View-Controller）發(fā)展到更具體的模式（如 Intercepting Filter）。
  
  表 1：Web 表示模式
  
  模式 問題 關(guān)聯(lián)的實(shí)現(xiàn)途徑
  Model-View-Controller 如何讓 Web 應(yīng)用程序的用戶界面功能實(shí)現(xiàn)模塊化，以便可以方便地單獨(dú)修改各個(gè)部件？ 在 ASP.NET 中實(shí)現(xiàn) Model-View-Controller
  Page Controller 如何以最優(yōu)方式為中等復(fù)雜程度的 Web 應(yīng)用程序構(gòu)造控制器，以便在避免代碼重復(fù)的同時(shí)實(shí)現(xiàn)重復(fù)使用和靈活性？ 在 ASP.NET 中實(shí)現(xiàn) Page Controller
  Front Controller 如何以最優(yōu)方式為非常復(fù)雜的 Web 應(yīng)用程序構(gòu)造控制器，以便在避免代碼重復(fù)的同時(shí)實(shí)現(xiàn)重復(fù)使用和靈活性？ 在 ASP.NET