WebForums.NET提供者模型-一個早期的原型
　　相對于微軟建議使用的提供者模型，Andy的提供者模型含有一些不足。一方面，WebForums.NET中提供了單個抽象基類，所有的API定義都聚集在這個類中。其負面作用在于，如果一個客戶僅想定制系統的一小部分，例如用戶信息的存儲方式，那么他必須提供該系統中所有方法的實現。一種更好的方案是，為系統中的每一個邏輯實體創建一個抽象基類。例如，對于一個在線消息板應用程序來說，它可能需要一些類，如UsersProvider，ForumsProvider，PostsProvider，等等。然而，在你提供給一個客戶的提供者數目之間也存在一個平衡問題。更多提供者允許更為細致的系統定制，但是也會相應地提高要求的配置標記的數量。
　　另外，我已經展示了對WebForums.NET的提供者模型實現代碼的作了進一步改進，以便使其更相似于微軟在ASP.NET2.0中所使用的代碼。我認為，Andy的想法應該是提供者模型的先驅，盡管微軟的提供者模型實現更為清晰且更強壯一些。
　　一方面，WebForums.NET在2002年三月為微軟所收購；另一方面，RobHoward及其他人又在系統中加入了大量的新特征并且在ASP.NET論壇中以自由方式發行它。TodayRob及其小組成員已經把ASP.NET論壇變成了一個CommunityServer（它簡直把博客、論壇、畫廊、列表服務器、新聞閱讀器等全部融為一體）。今天，Andy所創建的概念與實現被廣泛應用于ASP.NET論壇和CommunityServer中，甚至被應用于許多核心ASP.NET2.0組件中。
　　三、提供者模型優點
　　提供者模型提供許多優點。首先，在代碼和后端實現之間存在清晰的分離。不管認證一個用戶的代碼是針對一個SQLServer2000數據庫的Users表還是針對于一個活動目錄存儲，從頁面開發者的觀察看來代碼都是相同的：　　

DataProvider.Instance().AuthenticateUser(username，password)；

　　而且，后端實現變化是透明的。
　　因為系統架構師被鼓勵創建默認的實現，所以提供者模型提供了兩種世界的最好結合：如果對默認實現已經比較滿意，那么系統會按預期進行工作；對于需要定制系統的用戶來說，他們盡管定制好了而不必干擾現有代碼或編程邏輯。這個設計模式也使得原型化和靈敏開發容易許多。例如，在早期系統使用階段，僅使用默認實現可能更容易。然而，以后你可能需要定制某些方面以便把該工作與你的公司的現有系統集成到一起。這時，你可以通過提供者模型實現需要的定制。這意味著，不需要改變你的早期工作來反映后端實現的變化。
　　就象許多好的設計模型一樣，提供者模型也提供了開發者之間的職責分離。這樣以來，一部分開發者可以使用他們精通的系統API進行工作，而另一部分開發者可以專注于后端實現和定制任務開發；而且，這兩組人員可以工作在同一個系統上而不會相互干擾。而且，如果他們所使用的系統是一種工業標準（例如ASP.NET2.0），那么這兩類任務中的技能都可以被容易地移植到未來的工作中。
　　四、ASP.NET2.0提供者模型
　　ASP.NET2.0在全部其架構中都利用提供者模型。例如，它的許多子系統-會員，站點導航，個性化等都利用了提供者模型技術。而且，每個子系統都提供一種默認實現，但也能使客戶定制其功能以滿足他們自己的需要。例如，ASP.NET2.0的站點導航部分允許一個頁面開發者定義他們網站的可導航的結構。然后，這些數據就可以被各種Web控件所使用以便顯示站點地圖、樹狀視圖或菜單-它們能夠高亮站點的導航并且/或者顯示用戶的站點位置。除了與導航相關的Web控件外，站點導航API還提供了一組方法用于實現與網站導航信息的交互。
　　默認地，站點的可導航信息必須以一個正確格式化的XML文件編碼。這種數據存儲方式是，默認站點導航被硬編碼使用。然而，ASP.NET2.0的提供者模型可以使你更容易地使用你自己的數據存儲來實現站點導航。例如，在一個我當前開發的工程中，使用的一個數據庫包含站點中的頁面信息以及不同的用戶擁有頁面中什么樣的許可權。不是在一個XML文件中重新定義這些信息并且必須努力保持兩份信息的及時更新；而是，通過利用ASP.NET2.0中的站點導航功能，我可以簡單地創建一個提供者類，它能夠直接與數據庫信息工作。一旦創建這個類并且在網站的配置中指定，導航Web控件就可以根據存儲在數據庫中的應用程序的定制導航信息進行工作。(注意：在本文成文之時，這個工程使用的仍然是ASP.NET1.x；然而，這個例子卻有希望能夠向你展示提供者模型的優點。)
　　作為個人，我想，提供者模型只是ASP.NET2.0提供的最優秀的遷移特征之一。ASP.NET2.0提供了很多開發者在1.x版本中必須定制的新特征。如果這些2.0版本的新特征使用過于"僵硬"的實現方式，那么它將阻止基于定制方案的正在使用中的1.x應用程序向它的遷移，因為許多新的ASP.NET2.0Web控件都使用了這些新的子系統。然而，有了提供者模型后，我們就可以把我們的1.x應用程序升級到2.0版本并且創建一個提供者以便使2.0版本的新的子系統與我們的定制方案集成到一起。這意味著，當遷移到2.0版本時，我們可以使用新的Web控件并且使它們通過提供者模型而自然地使用我們的現有系統。
　　五、補充信息
　　隨著提供者模型成為ASP.NET2.0中的一個重要組成部分，微軟出版了很多關于這個主題的文章。如果你想了解更多這方面的信息，那么我鼓勵你閱讀一下RobHoward的兩篇文章：
　　◆《提供者模型設計模式與規范》；
　　◆《ASP.NET1.x提供者模型》。
　　其中，第二篇文章分析了如何把提供者模型應用于你的ASP.NET1.x應用程序。還有兩篇文章討論了ASP.NET2.0的站點導航子系統中的提供者用法：
　　◆《理解和擴展ASP.NET2.0中的站點導航系統》，作者DavidGristwood；
　　◆《定制ASP.NET2.0中的提供者》，作者MorganSkinner。
　　注意，微軟還發行了另外一個提供者開發工具包，它也用于創建ASP.NET2.0提供者。而且，還有一篇不錯的文章《ASP.NET2.0提供者模型》可供你參考。
　　六、結論
　　當創建具有各種要求的大量客戶所使用的系統時，一種"僵硬"的API實現可能會"嚇壞"了開發者；這種"僵硬"的實現往往會強迫客戶同意且被鎖定于系統架構師的"視野"之內。而一般地，公司往往更對能夠與他們的現有方案協同工作的應用程序和框架感興趣而不是強迫他們的方案服從供應商提供的系統。
　　提供者模型提供了一種打破這種"僵硬"的實現問題的方法。借助于提供者模型，系統就能夠靈活地使用擴展特定基類的任何類。這樣以來，客戶可以創建他們自己的包括他們的定制邏輯和業務規則的派生類。而且，這些新類可以無縫地插接到系統中，而不必干擾應用程序中的現有代碼或任何自創建以來的新的定制代碼。
　　總之，提供者模型在ASP.NET2.0中得到普通使用；而且這些概念也可以應用于ASP.NET1.x應用程序中。

      上一篇：深入ASP.NET 2.0的提供者模型(1)