理解Asp.net 提供者模型（第2部分）

  译自Understanding ASP.NET Provider Model – Part 2

 

引言

在第1部分中，我们了解了ASP.NET提供者模型的基本思想。在这部分里，我将阐释ASP.NET 内建提供者的结构。我们重点对成员资格提供者进行解剖。

 

成员资格提供者的基类

先看看下面这幅图：

你已经看到，所有提供者的基类是ProviderBase。ProviderBase类位于System.Configuration.Provider名字空间中，它是一个抽象类，为继承链提供了模板。这个类的一个重要方法是Initialize()。这个方法用于从web.config文件中读取提供者的配置信息，然后初始化提供者。

 

MembershipProvider类位于System.Web.Security名字空间中，它从ProviderBase类继承，并且添加了成员资格的特定成员（特别是用户创建和管理相关成员）。这个类也是抽象类。

 

最后，SqlMembership类从MembershipProvider类继承，它位于System.Web.Security名字空间中。这是一个实体类，实现了ProviderBase和MembershipProvider类中定义的属性和方法，专门用于SQL SERVER数据库。

 

其它提供者类

其它提供者，如SQL角色提供者和SQL特性提供者，也具有相似的类结构。

例如，SQL角色提供者的继承链如下：

ProviderBase -> RoleProvider -> SqlRoleProvider

SQL特性提供者的继承链：

ProviderBase -> SettingsProvider -> ProfileProvider -> SqlProfileProvider

 

抽象类或接口

在.NET2.0中，微软的设计指导方针发生了变化。在上一个版本的.NET中，他们常常使用接口来为框架类提供模板。例如，在ADO.NET 1.X中，所有的数据提供者类实现了一定数量的通用的接口（IDbConnection,IDbCommand等）。虽然ADO.NET 2.0中仍然实现了这些接口，但这主要是为了兼容。在ADO.NET 2.0中，没有使用接口作为模板，而是采用了抽象类。这对于提供者类产生同样的效果。可能的原因有：

• 抽象类能够提供一些实现，但是接口却不能。
• 接口一旦实现之后就不能再更改，否则那会使所有实现了接口的类被破坏。
• 使用抽象类，可以对基类进行改进，而不会对继承于它的子类产生不良影响。

 

总结

本文深入解析了ASP.NET内建的提供者的结构。在下一篇文章中，我们将使用本文第1部分和第2部分的知识来创建自定义的成员资格提供者。