在本文中，我們將詳細探討提供者模型並分析如何把它應用於ASP.NET 2.0開發中，具體內容包括：API實現、提供者模型優點、ASP.NET 2.0提供者模型和補充信息等。
一、引言
早在2001年，我就著手開發一個ASP.NET在線消息板應用程序WebForums.NET。其目的是創建一個基於ASP.NET的消息板系統，而且該系統可以容易插入到一個現有網站中。構建這樣一個端對端應用程序的特別挑戰之一就是，要為客戶提供一種方式以便能夠把它集成到他們自己的系統中去。例如，一個在線論壇明顯需要使用某種數據存儲來存儲用戶信息、論壇、回寄信息等；但是，最好不要把客戶鎖定到一種特定的數據存儲中。也就是說，你不應該說，“我的應用程序必須使用微軟的SQL Server 2000”；因為這樣的話，使用Oracle或Access的客戶怎麼會使用你的軟件呢？
另一個集成到客戶現有數據中的問題是，所有的在線論壇站點都提供用戶帳戶和一種創建新帳戶的方式。典型情況下，這被建模為一個論壇架構（以一個數據庫中的Users表形式存在）。但是，客戶很可能已經有他們自己的擁有成千的用戶帳戶的數據庫表。或者，一個客戶可能想在一個內部網設置中使用該論壇，並且想使用活動目錄而不是某種數據庫表來認證和存儲用戶信息。因此，當一個論壇軟件系統創建一個Users數據庫表並對其客戶說"這就是你存儲用戶的方式"時，那些已經擁有現有基礎結構和用戶數據的客戶很可能會疏遠這樣的軟件。
因此，當你使用一種“僵硬”的API構建一個系統時，會產生特別的挑戰。一種“僵硬”的API不是提供一種方式來定制邏輯而是硬編碼實現細節（例如，你必須使用SQL Server作為你的後端數據存儲，且在這個數據庫有一個Users表，並將在其中存儲所有的用戶信息）。然而，通過使用提供者設計模式，你可以輕易地打破這種"僵硬"性。借助於提供者設計模式，系統架構師只需要定義API，至於編程功能則由系統來提供。對於一個在線論壇應用程序來說，這可能包括一個具有例如Authenticate(username，password)和GetUserDetails(username)等方法的Users類。
提供者模型的優秀在於客戶實現方案可以指定一個系統應該使用的定制類。這種定制類必須實現系統的良好定義的API；但是，它允許無縫地插入任何定制實現。也就是說，一旦定義這個API，系統實現者可以創建一個使用SQL Server和一個Users表的默認的具體實現-大多數客戶可以直接使用之而不必要作任何修改。那些有定制需要的客戶（他們想使用Oracle或以另外一些方式存儲用戶數據）可以創建他們自己的類，該類提供必要的功能並且把它們插入到這些客戶的系統中。
其實，提供者設計模式被應用於整個ASP.NET 2.0實現中。當然，網上也存在一些如何在ASP.NET 1.x應用程序中使用這一功能的教程。
在本文中，我們將詳細探討提供者模型並分析如何把它應用於ASP.NET 2.0開發中。
二、打破“僵硬”的API實現
在我早期的WebForums.NET開發中，我認識到，這種"僵硬"的API實現將會成為一個問題。我的軟件設計目標之一就是：盡可能靈活且可定制，並且使用戶使用SQL Server，而且我的用戶數據模型實現應該看起來充其量只是有些限制性。為了克服這些問題，我構建了一個包含下面兩部分的系統：
1.一組定義了系統的核心功能的抽象基類；
2.能夠在運行時刻動態地加載一個擴展抽象基類。具體地說，該代碼負責檢查包含一個＜ConfigSetting＞節（該節中給出要使用的類的完全限定名）的Web.config文件。
借助於這一架構，我可以通過一系列抽象基類來定義系統的功能，並使用SQL Server 2000和Users表來提供這些類的具體實現。滿足這一配置的客戶可以只管使用該應用程序，並且一切將工作良好，且不需要他們編寫一行代碼。然而，那些需要定制的開發者們可以通過創建他們自己的派生自適當的抽象基類的類來實現。通過簡單地把該程序集放到應用程序的/bin目錄並更新Web.config文件，他們可以讓系統使用這個新類。具體地說，WebForums.NET發行中帶有一個抽象基類DataProvider，它清楚地列舉出了系統中的所有方法，類似如下：
public abstract class DataProvider
{
public abstract bool AuthenticateUser(string username，string password);
public abstract User GetUserInfo(string username);
...
public static DataProvider Instance()
{
...
}
} 
