在.NET 2.0中，引入了Provider模式后，大大了提高了框架本身的可扩展性。以Membership，Roles，Profile组成的用户管理组件（包括页面个性化信息）就是以这种模式为核心构建起来的，在asp.net 2.0中，利用系统提供的API可以很容易的实现用户管理，角色管理，用户个性化信息的管理。
用户管理的三个组件是相互关联的，而且在数据设计上也是做了非常严格的数据约束。一个数据库可以存放多个系统的用户，以便用户的统一管理，每个用户都有一个ApplicationId字段来标识它是属于哪个系统的用户。
如上图所示，表与表之前看似有着极其复杂的关联关系。
1．aspnet_Application ：用来保存系统名的，每一个不同的系统名都会生成一个唯一的ID，这个ID是与其它关联关系的外键。
2．aspnet_Users ：用户表，但是它只保存了用户ID基本不会变的信息，并且会有一个Uniqueidentifier类型的字段UserId来作为每个用户的唯一标识(并且是主键)，以方便与其它表的关联。值得注意的是还有一个ApplicationId字段，通过这个字段与aspnet_Application进行关联，以此来将区分用户是属于哪个系统的。由于UserName字段本身并不是主键，所以它是可以有重复值的，但不是说一个系统允许存在相同的用户名。正是ApplicationId字段来标识相同的用户名是属于不同的系统的。ApplicationId字段的作用就在于此，所以你可以看到很多表中都有这个字段的存在。
3．aspnet_Membership ：保存着用户的一些可变（不可变）的基本信息。
|
字段 |
作用 |
|
ApplicationId |
标识用户属于哪个系统 |
|
UserId |
与aspnet_Users关联的字段 |
|
Password |
加密或未加密的密码 |
|
PasswordFormat |
指示密码的存储格式（明文或使用的加密码算法） |
|
PasswordSalt |
用于辅助密码验证的字段（不可逆算法进行密码验证时所需） |
|
MobilePIN |
手机PIN码，同样可以唯一标 |
|
|
Email (可配置Email是否必须唯一) |
|
LoweredEmail |
小写的Email |
|
PasswordQuestion |
密码安全问题(可配置是否必须) |
|
PasswordAnswer |
密码安全问题答案 |
|
IsApproved |
用户是否已认证(为0时用户无法登录) |
|
IsLockedOut |
用户是否已锁定（可配置密码重试次数，超过则自动锁定该用户） |
|
CreateDate |
创建时间 |
|
LastLoginDate |
最后登录时间 |
|
LastPasswordChangedDate |
最后修改密码的时间 |
|
LastLockoutDate |
最后被锁定的时间 |
|
FailedPasswordAttemptCount |
密码重试次数 |
|
FailedPasswordAttemptWindowStart |
密码失败尝试窗口打开 时间 |
|
FailedPasswordAnswerAttemptCount |
安全密码重试次数 |
|
FailedPasswordAnswerAttemptWindowStart |
类同FailedPasswordAttemptWindowStart |
|
Comment |
其它自定义信息 |
从这些可以看到，在aspnet_Membership表存储着一些用户的公共属性信息。根本不同的需求的，我们可能还需要其它的一些自定义字段，在这种情况下最好不要直接修改这个表，而是应该新建一个表，或利用Profile功能来实现。
4．aspnet_Profile ：存储着用户的一些个性化信息。由于个性化信息的字段是可变的，所以它采用了一种比较灵活的存储方式，类似于：property1:value1;property2:value2的形式（具体分隔符可能有误）来存储多个可变的属性值。再通过解析，分解出正确属性和值。
5．aspnet_Roles ：存储系统的所以有角色，同样用ApplicationId来标识该角色属于哪个系统所有的。
6．aspnet_UsersInRoles ：多对多的关系表，存储哪些用户属于哪些角色。
7．Aspnet_Paths,aspnet_PersonalizationPerUser,aspnet_PersonalizationAllUsers：这几个表组合起来存储个性化页面设置，配合WebPart使用。
用户数据库就是由这些表组成的，理解了数据库的结构后，再来看待整个asp.net 2.0用户管理功能就会有比较清晰的认识了。另外两个表与用户管理没有直接关系的：aspnet_WebEvent_Events，用于记录系统在运行过程中去现的一些异常信息，需配合Health monitor使用；aspnet_SchemaVersions用于记录当前的框架版本信息，默认已经有记录了。
二、如何注册所需的数据库及存储过程。
了解了数据库结构后，接下来要解决的是就是如何创建这样一个数据库了。我们不可能手工的去创建这些表和存储过程的，当然后去手工去运行一段SQL语句也不是有点麻烦的。不用担心，.NET 2.0中已经提供相关的工具来注册这样一个数据库了，运行.NET命令行窗口，运行aspnet_regsql命令，会出现向导窗口。一段解析性提示进入下一步：
两个选项分别为配置aspnet数据库和删除已配置的aspnet数据库，进入下一步后
输入所需的数据库验证信息，在Database字段处需要注意：如果有选择已有的数据库，那这些表和存储过程将被创建到已有的数据库中；如果输入不存在的数据库名，那么将会创建一个新的数据库，存放这些表和存储过程，默认数据名为aspnetdb。再两步以后就会完成了数据库的注册了。
其中如果是express数据库，可以用下列命令行，数据库会创建到C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data目录下。
aspnet_regsql -C "Data Source=.\SQLExpress;Integrated Security=True;" -A all -d "test2.mdf"
aspnet_regsql 命令还可以做很多事，可以参考MSDN得到更多的帮助。
三、配置文件的支持。
Provider模式非常依赖配置文件支持，实际上它是创建型设计模式的一种很直接的应用。由于框架内部调用都是抽象类型的接口，所以要给通过配置文件给这些抽象类提供具体的实现类，并配置一些所需的参数。在asp.net 2.0的web.config文件中，提供了对这些配置的直接支持，并且还可以很容易的进行扩展。
四、接口支持。
继承了.NET 框架的优良传统，整个的Membership,Roles,Profile等功能都提供了非常简单的API供开发人员调用，Membership,Roles都被封装成静态类，并且重载了非常多的方法重载，以方便调用。而Profile更是在VS 2005 IDE的帮助下，可以动态生成类型定义，支持设计时的属性调用。
五、其他一些参考文章
Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 3
Integrating Customized Roles, Membership and Profiles in ASP.NET 2.0
