本系列文章介绍了ASP.NET2.0的Provider模型，本文是第二部分，原文请参考如下链接：
http://www.dotnetbips.com/articles/displayarticle.aspx?id=493
在第一部分，我们学习了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模型