深入ASP.NET 2.0的提供者模型(2)
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应用程序中。
