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模型

转载于:https://www.cnblogs.com/think-jerry/archive/2007/05/21/753636.html