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更接近于業務邏輯層。
（本篇完）
浙公網安備 33010602011771號