引言
在第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部分的知识来创建自定义的成员资格提供者。