ASP.NET2.0 Provider模型（二）

   在第一部分，我們學習了ASP.NET Provider模型的基本概念，本文將概述ASP.NET內建Provider模型的架構結構。具體的說我們將討論Membership的Provider模型

 

membership Provider的基礎類

 
先看一下下面這張圖

     正如您所看到的，所有Provider模型的基礎類都是ProviderBase。ProviderBase類駐留在system.configuration.dll 集裡的System.Configuration.Provider命名空間裡，該類被標記為abstract，它能夠作為模板提供給繼承者使用。該類的一個重要的方法是Initalize()。該方法通常用來從設定檔web.config裡讀取配置的資訊並初始化Provider模型

 

    MembershipProvider類駐留在System.Web.Security命名空間裡，該類是由ProviderBase類繼承而來的，並增加了成員關係所需要的特性方法和屬性（這些方法和屬性是建立和系統管理使用者專用的），該類同樣被標記為abstract。

  最後，SqlMembership類駐留在System.Web.Security 命名空間，它是從MembershipProvider類派生。這是一個具體的類，它可以執行從ProviderBase和MembershipProvider定義的專門用於執行SQL Server資料庫的屬性和方法。

其它的Provider類

   類似的類繼承關係可以在諸如SQL Role，SQL Profile Provider模型裡看到。例如SQL Role Provider繼承模型的網站連結如下：

ProviderBase-->RoleProvider－－>SqlRoleProvider

 

SQL Profile Provider的繼承模型網站連結如下：

ProviderBase -> SettingsProvider -> ProfileProvider -> SqlProfileProvider

 

是選擇抽象類別還是選擇介面

    在ASP.NET2.0你可以看到微軟在設計指導方針的變更。在.NET2.0以前的版本裡，他們通常更多的依賴介面來為架構的類提供模板模型，例如ADO.NET1.X裡的資料Provider類就是執行了常規的共通介面（IDbConnection,IDbCommand等）。儘管ADO.NET2.0繼續支援這些介面，但是這可能是為了相容的原因。 

   在ADO.NET2.0裡，他們更喜歡選擇抽象類別。Provider就是使用了抽象類別。 不是利用介面產生的模板而是選擇抽象類別，可能的原因我感覺是：

 抽象類別可以執行某些功能而介面則不能

 介面定義後將不便於更改，因為變更將破壞從該介面定義的類的。

 使用抽象類別，基類可以不干擾子類

 

  總結：文本深入介紹了ASP.NET Provider模型，在本系列的下一部分，我們將使用第一，二部分的知識來自訂自己的Membership模型