.NET架構與模式探索

2019-11-17 04:58:13

字體：大中小

來源：轉載

供稿：網友

　什么是架構

　　軟件體系結構通常被稱為架構，指可以預制和可重構的軟件框架結構。架構尚處在發展期，對于其定義，學術界尚未形成一個統一的意見，而不同角度的視點也會造成軟件體系結構的不同理解，以下是一些主流的標準觀點。　　ANSI/IEEE 610.12-1990軟件工程標準詞匯對于體系結構定義是：“體系架構是以構件、構件之間的關系、構件與環境之間的關系為內容的某一系統的基本組織結構以及知道上述內容設計與演化的原理(PRinciple)”。　　Mary Shaw和David Garlan認為軟件體系結構是軟件設計過程中，超越計算中的算法設計和數據結構設計的一個層次。體系結構問題包括各個方面的組織和全局控制結構，通信協議、同步，數據存儲，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案之間進行選擇。Garlan & Shaw模型^[1]的基本思想是：軟件體系結構={構件(component),連接件(connector)，約束(constrain)}．其中構件可以是一組代碼，如程序的模塊；也可以是一個獨立的程序，如數據庫服務器。連接件可以是過程調用、管道、遠程過程調用(RPC)等，用于表示構件之間的相互作用。約束一般為對象連接時的規則，或指明構件連接的形式和條件，例如，上層構件可要求下層構件的服務，反之不行；兩對象不得遞規地發送消息；代碼復制遷移的一致性約束；什么條件下此種連接無效等。　　關于架構的定義還有很多其他觀點，比如Bass定義、Booch & Rumbaugh &Jacobson定義、Perry & Wolf模型[7]、Boehm模型等等，雖然各種定義要害架構的角度不同，研究對象也略有側重，但其核心的內容都是軟件系統的結構，其中以Garlan & Shaw模型為代表，強調了體系結構的基本要素是構件、連接件及其約束（或者連接語義），這些定義大部分是從構造的角度來甚至軟件體系結構，而IEEE的定義不僅強調了系統的基本組成，同時強調了體系結構的環境即和外界的交互。

　什么是模式

　　模式（Pattern）的概念最早由建筑大師Christopher Alexander于二十世紀七十年代提出，應用于建筑領域，八十年代中期由Ward Cunningham和Kent Beck將其思想引入到軟件領域，Christopher Alexander將模式分為三個部分：首先是周境（Context，也可以稱著上下文）,指模式在何種狀況下發生作用；其二是動機（System of Forces）,意指問題或預期的目標；其三是解決方案（Solution）,指平衡各動機或解決所闡述問題的一個構造或配置（Configuration）。他提出，模式是表示周境、動機、解決方案三個方面關系的一個規則，每個模式描述了一個在某種周境下不斷重復發生的問題，以及該問題解決方案的核心所在，模式即是一個事物（thing）又是一個過程(process)，不僅描述該事物本身，而且提出了通過怎樣的過程來產生該事物。這一定義已被軟件界廣為接受。　　軟件模式的應用對軟件開發產生了重大的作用，主要表現在：

軟件模式是人們在長期的設計軟件、治理組織軟件開發等實踐中大量經驗的提煉和抽象，是復用軟件設計方法、過程治理經驗的有力工具。模式類似于拳擊中的組合拳，它提供了一系列軟件開發中的思維套路。如，通過模式的使用，有利于在復雜的系統中產生簡潔、精巧的設計。
軟件模式為我們提供了一套簡潔通用的設計、治理、組織方面的詞匯，同時模式也為我們提供了一個描述抽象事物的規范標準，可大大促進軟件開發過程中人與人之間的交流，而軟件開發中的交流是至關重要的，“軟件項目失敗的原因最終都可追溯到信息沒有及時準確地傳遞到應該接收它的人”。

　架構和模式的關系

　　因為架構(Architecture)和模式(Pattern)在當前的軟件開發中經常地被提及，可是很多人輕易混淆這兩個術語，而對此，學術界也沒有一個非常統一的定義。　　架構和模式應該是一個屬于相互涵蓋的過程，但是總體來說Architecture更加關注的是所謂的High-Level Design,而模式關注的重點在于通過經驗提取的“準則或指導方案”在設計中的應用，因此在不同層面考慮問題的時候就形成了不同問題域上的Pattern。模式的目標是，把共通問題中的不變部分和變化部分分離出來。不變的部分，就構成了模式，因此，模式是一個經驗提取的“準則”，并且在一次一次的實踐中得到驗證，在不同的層次有不同的模式，小到語言實現(如Singleton)大到架構。在不同的層面上，模式提供不同層面的指導。根據處理問題的粒度不同，從高到低，模式分為3個層次：架構模式(Architectural Pattern)、設計模式(Design Pattern)、實現模式(Implementation Pattern).架構模式是模式中的最高層次，描述軟件系統里的基本的結構組織或綱要，通常提供一組事先定義好的子系統，指定它們的責任，并給出把它們組織在一起的法則和指南。比如，用戶和文件系統安全策略模型，N-層結構，組件對象服務等，我們熟知的MVC結構也屬于架構模式的層次。一個架構模式經常可以分解成很多個設計模式的聯合使用。設計模式是模式中的第二層次，用來處理程序設計中反復出現的問題。例如，[GOF95]^[2]總結的23個基本設計模式——Factory Pattern, Observer Pattern等等。實現模式是最低也是最具體的層次，處理具體到編程語言的問題。比如，類名，變量名，函數名的命名規則；異常處理的規則等等。
　　相對于系統分析或者設計模式來說，體系結構從更高的層面去考慮問題，所以關注的問題就體現在“不變”因素上，比如系統部署中，更加關心應用程序的分層分級設計，而在這個基礎之上提出的部署方案，才是架構考慮的重點。體系結構關心應用程序模式，更加體現在通過技術去解決這些業務差異帶來的影響，關心是否是分布式應用程序，關心系統分層是如何設計，也關心性能和安全，因此在這樣的情況之下，會考慮集群，負載平衡，故障遷移等等一系列技術。　　希望通過定義的方式來區分架構和模式是不太可能的，因為本來就是交互交叉和提供服務的，它實際上是架構模式，而不是設計模式。在大部份情況下，表現為下面幾個設計模式之一：Strategy模式、Mediator模式、Composite模式、Observer模式。對于熟悉架構設計的系統架構師而言，似乎可以用如下來解釋架構和模式之間的關系：架構是Hight-Level Design,著眼于不同業務中共性的解決方案，而模式是General Principle(通用原理)。

　企業解決方案的構建模式

　　企業級業務解決方案是公司實現其業務的賭注，它們通常極其復雜，而且性能必須不負眾望。它們不僅必須具有高可用性和伸縮性以應對不可預知的使用，而且還必須具有適應性和預見性以適應快速變化的業務要求。最佳解決方案是那些由一組更小的、簡單的、能夠可靠且有效地解決簡單問題的機制組成的解決方案。在構建更大、更復雜的系統過程中，將這些簡單的機制組合在一起，從而形成更大的系統。對這些簡單機制的熟悉來之不易。它通常存在于有經驗的開發人員和體系結構設計者的頭腦中，并且是他們潛意識中自然帶到項目中的重要知識。　　模式對于開發人員和體系結構設計者非常有用，因為它們：

記錄能夠正常工作的簡單機制。
為開發人員和體系結構設計者提供通用的詞匯和分類法。
答應以模式組合的方式簡明扼要地描述方案。
答應重復使用體系結構、設計和實現決策。

　模式可以記錄簡單機制

　　模式描述給定上下文中反復出現的問題，并基于一組指導性影響因素來建議解決方案。解決方案通常是一種簡單的機制，是為了解決模式中所標示出的問題而一起工作的兩個或多個類、對象、服務、進程、線程、組件或節點之間的協作。　　您正在構建一個報價應用程序，其中有一個類負責治理系統中的所有報價。很重要的一點是，所有報價都應與該類的一個（而且只與一個）實例進行交互。如何構造您的設計，以便從該應用程序中只能訪問該類的一個實例？　　解決該問題最簡單的方案就是創建一個具有私用構造函數的QuoteManager類，以便任何其他類都不能實例化它。此類包含QuoteManager的一個靜態實例，并使用名為GetInstance()的靜態方法返回。此代碼大體如下所示：public class QuoteManager
{
    //注重：僅適用于單線程應用程序
    private static QuoteManager _Instance = null;

    private QuoteManager() {}

    public static QuoteManager GetInstance()
    {
        if (_Instance==null)
        {
            _Instance = new QuoteManager ();
        }
        return _Instance;
    }

    //... QuoteManager提供的函數
}　　您可能已經像其他許多開發人員那樣通過類似的方式解決過類似的問題。實際上，注重反復出現的問題并尋求解決方案的模式作者已經屢次發現了這種實現，提取出了通用解決方案并將這種問題-解決方案對稱為Singleton模式[GOF95]。

　問題-解決方案對模式

圖1 簡化的Singleton模式　　通過將圖1中簡化的模式示例與QuoteManager源代碼進行比較，闡明了模式（通用問題-解決方案對）和模式應用程序（針對非常具體的問題的具體解決方案）之間的區別。模式級別的解決方案是多個類之間簡單但極其順暢的協作。模式中的通用協作專門適用于QuoteManager類，提供了用來控制報價應用程序中實例化的機制。顯然，您可以稍微修改一下某種模式以滿足局部的特定要求，所以同一種模式可以應用于無數個應用程序。　　所編寫的模式提供了一種記錄簡單且經過證實的機制的有效方法。模式是以特定格式編寫的，這一點對于裝載復雜思想的容器非常有用。這些模式在被記載和起名之前，就早已存在于開發人員的大腦及其代碼中。 QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器

　位于不同級別的模式

　　模式存在于多個不同的抽象級別中。考慮另一個示例（這次所處的抽象級別比源代碼要高一級）：　　您要設計一個基于Web的報價應用程序，其中包含大量業務和表示邏輯，這些邏輯反過來依靠大量平臺軟件組件來提供適當的執行環境。如何在高級別組織系統以使其在具有靈活、松耦合性的同時仍具有高內聚性？　　此問題的解決方案之一涉及到按一系列層來組織系統，每層包含大致位于同一抽象級別的元素。隨后，確定每一層中的依靠性，并確定采用嚴格還是寬松的分層策略。接著，決定是打算創建自定義的分層方案，還是采用以前由其他人記錄的分層方案。在本例中，假設您決定使用眾所周知的分層策略：表示、業務邏輯和數據訪問各占一層。圖2顯示了分層方案的可能外觀。 .NET架構與模式探索（圖二）

圖2 報價應用程序的層　　假如您總是按這種方式設計系統，說明您已經在不依靠于任何廣義模式的情況下使用該模式。即便如此，您還可能因多種原因而希望了解支撐這種設計方法的模式。您可能迫切想知道為何經常以這種方式構建系統，或者可能在尋找更理想的方法來解決此模式不能完全解決的問題。使用層作為高級別組織方法是Layers（層）模式[Buschmann96]^[3]中描述的完善模式。圖3顯示了該模式的簡化版本。 .NET架構與模式探索（圖三）

圖3 簡化的Layers模式　　這個簡單的應用程序組織策略有助于解決軟件開發中面臨的兩個挑戰：依存關系的治理和對可交換組件的需求。假如在構建應用程序時沒有一個考慮周全的依存關系治理策略，會導致組件易損壞且不牢靠，從而導致對它們進行維護、擴展和替代時存在較大的困難，而且成本較高。　　Layers模式中的工作機制比Singleton中的工作機制更精細。對于Layers，首次協作是在設計時發生在類之間，這是由于分層組織將對更改源代碼所帶來的影響局部化，從而防止所做的更改貫穿到整個系統。第二次協作發生在運行時：某層中相對獨立的組件變得可與其他組件交換，再一次使系統其余部分不受影響。　　盡管Layers模式的通用性足以應用于諸如網絡協議、平臺軟件和虛擬機之類的領域，但是它無法解決企業類業務解決方案中存在的某些特定問題。例如，除通過分解來治理復雜性（由Layers解決的基本問題）外，業務解決方案開發人員還需要進行適當組織，以便有效地重復使用業務邏輯并保留與昂貴資源（如數據庫）的重要連接。解決此問題的方法之一就是使用Three-Layered application（三層應用程序）模式。圖4顯示了該模式的簡化說明。 .NET架構與模式探索（圖四）

圖4 簡化的Three-Layered Application　　同樣，在模式(Three-Layered Application)和模式應用程序（報價應用程序分層模型）之間存在區別。模式是有關應用程序組織主題的通用問題-解決方案對，而模式應用程序是通過創建具體的層來解決非常具體的問題。

　模式的優化

　　Three-Layered Application實際上是在Layers的基礎上進行的簡單優化；在Layers中確定的上下文、影響因素和解決方案仍適用于Three-Layered Application，但反之不行。也就是說，Layers模式約束著Three-Layered Application模式，而Three-Layered Application模式優化了Layers模式。　　您為某個發展迅速的成功企業構建了一個報價應用程序。現在，您希望通過向業務合作伙伴公開自己的報價引擎并將其他合作伙伴服務（如配送）集成到該報價應用程序中來擴展該應用程序。您將如何構造自己的業務應用程序以提供和享受服務？　　此問題的解決方案之一是通過將其他與服務相關的職責添加到每一層中來擴展Three-Layered Application。在業務層添加了以下職責：通過Service Interfaces（服務接口）向客戶應用程序提供一組簡化的操作。數據訪問層的職責拓寬到了數據庫和主機集成之外，以包括與其他服務提供者的通信。將數據訪問層中的這個附加功能封裝到服務接口組件中，這些組件負責連接到服務（同步和異步）、治理服務的基本會話狀態并向業務流程組件通知與服務相關的重大事件。　　Three-Layered Services Application（三層服務應用程序）（圖5）記錄了該問題-解決方案對。 .NET架構與模式探索（圖五）

圖5 簡化的Three-Layered Services Application　　將Three-Layered Services Application模式應用于報價應用程序示例將形成如下模型。 .NET架構與模式探索（圖六）

圖6 應用于報價應用程序的Three-Layered Services Application　　請注重這些模式之間的關系（請參閱圖7）。Layers引進了一個用來組織軟件應用程序的基本策略。Three-Layered Application優化了此概念，并將它限制在需要重復使用業務邏輯、靈活部署和高效使用連接的業務系統的范圍內。Three-Layered Services Application又在Three-Layered Application的基礎上進行了優化，并對設計進行了擴展，以便在提供和使用其來源千差萬別的數據和邏輯時，將這些數據和邏輯處理為粒狀元素。 .NET架構與模式探索（圖七）

圖7 相關模式的優
　　向特定層中添加其他類型的組件并不是治理這種日益增長的復雜性的唯一方法。正如復雜性所證實的那樣，設計人員通常在應用程序中創建其他層來承擔該職責。例如，一些設計人員將服務接口移到一個單獨的層中。而另外一些設計人員將業務層分隔成域層和應用程序層。在任何情況下，您有時可能會看到某些設計人員在使用此模式來滿足復雜要求時，有時會將這三層擴展到四層、五層或者甚至六層。與之相反，Layers模式也用在相對簡單的客戶端-服務器應用程序中。　　解決方案簡述：術語“解決方案”有兩種截然不同的含義：其一是表示模式本身的一部分（如某上下文中包含的問題-解決方案對）；其二是表示業務解決方案。在使用“業務解決方案”這一術語時，它是指專用來滿足一組特定的功能和操作業務要求的軟件密集型系統。軟件密集型系統意味著您不只是關心軟件，而且還必須將該軟件部署到硬件處理節點以提供整體的技術解決方案。而且，所考慮的軟件不僅包括自定義開發的軟件，而且包括購買的軟件基礎結構和平臺組件，所有這些都被集成在了一起。

　結束語

　　以.NET為代表的Microsoft產品線向我們展示了“架構為基礎，模式為指導”的企業解決方案設計理念，秉承微軟產品一貫以來的簡單易用以外，同時我們將看到使用.NET構建企業應用平臺上使用.NET的優勢。毫不夸張地說，.NET不是第一個體現架構和模式的軟件應用平臺，確是目前為止最后的實現了架構和模式的平臺，在隨后的文章介紹中，你將會發現，架構設計和模式應用會是如此簡單。　　[1] 《軟件體系結構（影印版）》，科學出版社2004年1月1日出版。Mary Shaw、David Garlan合著，原文書名《Software Architecture: Perspectives on an Emerging Discipline》。　　[2] GoF95，《設計模式——可復用面向對象軟件的基礎》，Erich Gamma、Richard Helm等著，英文版本《Design Patterns: Elements of Reusable Object-Oriented Software》，這是設計模式領域的經典之作，它結合設計實例從面向對象的設計中精選出23個設計模式，總結了面向對象設計中最有價值的經驗，并且用簡潔可復用的形式表達出來。　　[3] [Buschmann96] Buschmann，Frank，《Pattern-Oriented Software Architecture》，John Wiley & Sons Ltd，1996。中文版《面向模式的軟件體系結構》，2003年1月機械工業出版社出版。

上一篇：用VS2005生成數據庫連接字符串

下一篇：Ruby程序語言之數字、字符串和其它(1)