ASP.NET2.0 Provider模型(上) ——原理、模型與分析

摘要

“Provider”這個名詞對於研究ASP.NET2.0的朋友來講可謂是”司空見慣”了，地球人都知道ASP.NET2.0的MemberShip（成員資格管理）、SiteMapPath(網站地圖)、個人化等新特性都是基於Provider模型構建的。正因如此，對Provider模型的解理與熟悉直接影響著好些ASP.NET2.0新特性的運用。又因為關於Provider模型方面的資料(特別是中文的)實在少之又少，本著“人人為我，我為人人”的共用精神，決定把自己在運用Provider模型方面的心得跟大家分享一下，希望能作為ASP.NET2.0入門者的有用參考,同時也歡迎各位“High Hand”參與指導及補遺。

本系列文章將分上中下三部分，上篇《ASP.NET2.0 Provider模型(上)—原理、模型與分析》將著重於分析Provider模型的原理與結構；中篇《ASP.NET2.0 Provider模型(中)——模板與樣本》著重於實現，將以Provider模型模板作為樣本，講解Provider模型的參考實現；下篇《ASP.NET2.0 Provider模型(下)—ASP.NET2.0 MemberShip成員資格管理》將對ASP.NET2.0內建的新特性（成員資格管理）以Provider模型為導向分析其組成和它與“登入控制項”之間的關係。

 

主要內容

一、 Provider模型是何物

l        原則與模式

二、 Provider模型的組成

l        模型組成

l        ASP.NET2.0 Provider模型組成

l        Provider模型與軟體架構的關係

 

本文

 

概述

在ASP.NET2.0面世之前，Provider模型應該算是比較“低調”的,但隨著ASP.NET2.0的日盈普及，認識Provider模型成為了靈活運用MemberShip（成員資格管理）、SiteMapPath(網站地圖)、個人化等新特性的關鍵。如果忽略了Provider模型的存在，您瞭解的ASP.NET2.0將是不完整的。

可能很多初次接觸ASP.NET2.0的朋友都會產生一些疑惑：為什麼在網站的App_Data目錄會自動產生ASPNETDB.MDF資料庫呢？登入控制項為何非得依賴於SQLServer2005Express資料庫呢？想把資料存放區換成SQLServer2000、Orcale、Access甚至是MySQL的，行不？要使用登入控制項(或MemberShip)就必需使用自動產生的資料庫表（”aspnet_” 做首碼的表）來儲存資料嗎？……其實這一切都可以從Provider模型中找到答案。

本文作為本系列文章的上篇，由二部分組成：第一部分將介紹什麼是Provider模型及為什麼使用它（它解決了什麼問題）；第二部分將講述Provider模型的組成（參與者）和它們各自的職能。

 

一、 Provider模型是何物

其實Provider模型說白了就是一種設計模式。談到設計模式的話就可以從模式的概念中領悟Provider模型的“內含”。首先，需要瞭解的是Provider模型不是一個具體的產品，是一種設計思想。它不是微軟專屬的，不是在.NET環境下才能實現的。其次，Provider模型不是ASP.NET2.0專屬的，也不是迎合ASP.NET2.0的出現而產生的新的設計模式。只是.NET Framework 2.0對這種設計模式有內建支援（到後邊再討論），運用起來更加簡易方便；其實在Framework1.1，甚至是JAVA同樣可以實現Provider模型。

 

模式與原則

既然Provider模型是一種設計模式，咱們對它的討論就從模式的角度出發吧。大家都知道設計模式的定義就是“對被用來在特定情境下解決一般設計問題的類和相互連訊的對象的描述。”（GOF）。而我們第一步需要明確的就是它所解決的設計問題（應用情境），第二步就是要清楚它的各個參與者及各自的職能（第二節再討論）。

那Provider模型究竟解決了什麼設計問題呢？一句話概括：Provider模型解除了客戶代碼對特定儲存的依賴，使應用程式代碼與具體的資料訪問邏輯松耦。而以這種模型設計出來的應用將滿足OCP設計原則(對擴充是開放的，對代碼的修改是封閉的)，也就是說利用Provider模型開發系統，將對具體資料儲存有很靈活的擴充性。具體來說，我們的系統開發不再需要考慮最終的資料存放區是使用SQLServer，還是Orcale或者Access，甚至是XML。我們只需要選擇其中一種具體的資料存放區（通常是SQLServer）作為預設的實現；當需求發生改變時（客戶要求資料庫管理系統必須使用Orcale），需要做的動作就只有兩步，其一，根據Orcale資料庫做具體實作類別，其二，修改配置；而對於系統已編譯通過的代碼是不需要再修改並編譯，系統仍然是照常工作的。（具體實現將在下一篇中討論）

 

二、           Provider模型的組成

對Provider模型有了初步瞭解後，咱們開始對它作具體分析。如上所述，Provider模型是一種設計思想，所以本節會先對模型作一概念性分析，然後再結合ASP.NET2.0對Provider模型的內部支援具體分析，最後會討論Provider模型與軟體架構之間的關係。

 

Provider模型組成（概念性模型）

Provider模型從概念角度來分析，其參與者及各自的關係可歸納為：

 

 

主要由4種參與者組成，分別為：

1.    Provider抽象——該對象主要負責規劃資料訪問邏輯(抽象)。可以具體實現為抽象類別或介面。所謂的規劃也就是為模組需要執行的資料存取方法訂製方法簽名（包括所有重載），也就是設計所有模組相關的資料操作方法的傳回值、名稱、參數，但不做實現。

2.    Provider實現——該對象主要有二個職能。其一，也是最重要的職能是針對不同的資料存放區，實現（重寫）Provider抽象規劃的方法；其二，是定義、讀取及處理，可供使用者配置的屬性（如連接字串）。

3.    Provider服務API——該對象是上層應用代碼的編程介面。它的內部關聯了Provider抽象，並為Provider抽象中規劃的方法提供上層調用介面。從而滿足OCP原則，而且它是依賴於抽象的，所以還滿足DIP原則。當需要更改Provider抽象所裝載的實作類別對象時，需要做的就只是修改設定檔，而上層應用甚至Provider服務API內部都不需要更改任何代碼並重新發布。另外，因為使用了抽象（介面）編程，此對象還必須解決具體對象裝載的問題。（下一篇將提供了一種簡單實現方式）

4.    Provider配置——通過組態管理，可以讓使用者選擇Provider服務API中，Provider抽象所裝載的具體Provider實現對象。

 

ASP.NET2.0 Provider模型組成

如上所述，ASP.NET2.0內建了對Provider模型的支援，也就是提供了一種便捷的實現方式。主要體現為2.0新增的System.Configuration.Provider 命名空間。

結合上一部分的概念性模型作分析，System.Configuration.Provider命名空間中的ProviderBase抽象類別，為所有Provider模型的實現提供統一“規格”。也就是說想在2.0中實現內建支援的Provider模型，關鍵就在於Provider抽象需要繼承自ProviderBase抽象類別。

細心的朋友應該會留意到ProviderBase所在的命名空間是跟配置相關的，那它跟配置有關係嗎？一點兒也沒錯，2.0正是通過組態管理去解決Provider服務API中，需要使用的Provider抽象的具體對象裝載問題。通過MSDN可得知，ProviderBase的定義其實很簡單，關鍵成員就只有幾個：

l        Name屬性：組態管理代碼中使用的Provider執行個體名稱。

l        Description屬性：簡短描述。

l        Initialize方法：這個方法相當重要，Provider實現正是通過重寫它來完成Provider配置資料的讀取及處理的。需要強調的是Provider抽象雖然繼承自ProviderBase，但一般情況下Initialize方法是在Provider實現中重寫的。

另外，在System.Configuration.Provider命名空間下還有兩個類：其一，ProviderCollection就是ProviderBase的衍生類別的集合，其實就是在設定檔中被添加的具體Provider實現的集合；其二，ProviderException是Provider配置異常，這個類主要用於重寫ProviderBase的Initialize方法中，如上介紹Initialize方法用於讀取及處理使用者配置的具體Provider實現的屬性，其中核心思想就是：在Web.config中分別讀取具體Provider實現的屬性並處理，然後將處理完的的屬性從Provider設定物件中移除，最後再判斷設定物件中屬性集合裡是否還存在未處理的屬性，如果是，那麼代表使用者的配置有誤（配置了咱們“不認識”的屬性），此時便拋出ProviderException。（具體實現請看第三節）。

對2.0Provider模型有所瞭解後，可知2.0 Provider的模型圖只需上部分描繪的Provider概念性模型圖基地上作出少量改動。關鍵還是圖中的第一部分（Provider抽象）繼承自ProviderBase。ProviderBase也正是MemberShipProvider、RoleProvider、SiteMapProvider等新特性的Provider抽象的基類。（成員資格管理將在本系列文章的下篇再詳細討論）

 

Provider模型與軟體架構的關係

為了更好理解及運用Provider模型，本節的最後一部分將跟大家探討一下Provider模型與軟體架構之間的關係。

從上一部分的Provider模型概念圖中瞭解到，Provider模型位於軟體架構中的資料訪問層，咱們之前瞭解到的資料訪問層相關技術還有ADO.NET、DAAB2.0、企業庫DAAB等。那麼它們之間的關係又存在怎樣的關係呢？請看（此圖主要強調由下往上的層次關係）：

 

Provider模型與軟體架構之間的關係總結有以下幾點：

1.      Provider模型的核心參與者都位於資料訪問層

2.      在Provider模型中與資料訪問相關對象直接產生依賴的是Provider實現。

3.      Provider實現可以直接使用ADO.NET對象完成資料訪問操作，也可以使用DAAB至於企業庫DAAB。

4.      Provider模型比企業庫DAAB更接近於商務邏輯層。