asp.net 2.0 用户管理功能结构

在.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 (可配置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