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更接近于业务逻辑层。

 

转自：http://www.cnblogs.com/Ryu666/archive/2006/11/15/560588.html