摘要：一直困扰于DotNetNuke众为什么Users表和Aspnet_Users之类的表没有引用关联性，最近在看《DotNetNuke 4高级编程》的时候终于明白了。
Users表是DotNetNuke自己的用户表，而aspnet_之类的表asp.net 2.0的成员资格提供程序(Membership provider)，这些表用于用户验证的，就像用户的密码就存在表aspnet_membership中，而且密码是密文加密的。
下面是引用书中的一段内容。
为了实现成员资格提供程序的全部好处，认可用户信息可以从DotNetNuke具体化，并且能够存放在一个独立于主数据存储的数据存储中非常重要。例如，DotNetNuke可以使用Microsoft SQL Server作为它的数据库来存储内容和系统设置，但是成员资格提供程序可以用Windows验证、LDAP或者其他机制来处理验证和授权。因为安全可以使用提供程序模型具体化，所以确保成员资格提供程序的实现没有定制提供程序使用的任何代码或者数据库表非常重要。成员资格提供程序使用的数据表必须独立于其他核心DotNetNuke表。DotNetNuke数据和成员资格提供程序数据之间不能实施引用完整性(referential integrity)，而且不也不能使用级联删除(casecade delete)或者其他数据级同步方法。简而言之，就是所有的秘密都发生在DotNetNuke的业务逻辑层。
在实现成员资格提供程序过程中所面临的挑战之一，就是如何处理DotNetNuke内部支持、但成员资格提供程序并不支持的字段。理想情况下，解决方案应该将DotNetNuke中所有与验证/授权相关的表彻底替换为成员资格提供程序使用的表。但是无法实现这种解决方案，这是因为DotNetNuke中的验证/授权表已经与应用程序中许多已有的和必需的特性绑定在一起。例如，DotNetNuke的Users表中有UserID列，用来为每个用户存储一个唯一的标识符。而UserID在几乎所有的核心和第三方模块以及核心本身都大量使用。UserID的最大问题就是成员资格提供程序中没有这一字段。相反，成员资格提供程序使用了Useranme作为应用程序中用户的唯一标识。这里的挑战就是DotNetNuke需要一种方式来维持UserID，从而保持依赖于UserID的DotNetNuke功能。这只是一个由微软公司提供的默认成员资格提供程序不能处理的特性的例子。
最终，DotNetNuke需要维护一个附属表来支持不能由成员资格提供程序管理的DotNetNuke特性。这样做的目的就是为了在DotNetNuke表中维护足够的信息，以使DotNetNuke的功能不会丢失，并且还可以分担成员资格提供程序表中的一些负担。最终生成了一个与成员资格提供程序中的表对应的数据模型，如图所示。
注意，图上面的表和下面的表没有数据库关系。他们之间的连接只是为了标识他们之间在理论上的关系，而不是在数据库中的实际关系。
因为门户网站、配置文件、用户和角色的数据存储在多个不相关的表中，所以由业务逻辑层负责聚集这些数据。例如，如果不收集aspnet_Users表（位于成员资格提供程序中）和Users表（位于自身的DotNetNuke表中）中的数据，就无法得到一个完整的用户表示。
除了聚集外，成员资格提供程序使用的表中的数据必须与DotNetNuke自己提供的表中的数据自动同步。前面介绍过成员资格提供程序支持众多的数据存储，而且在ASP.NET2.0中，这些数据存储中的数据可以通过一个公用的应用程序配置实用工具管理。如果通过这个实用工具添加了一个用户，那么这个用户没有添加到DotNetNuke自己提供的表中。同样，如果成员资格提供程序使用了诸如LDAP的实现，那么用户将添加到LDAP中，而不是DotNetNuke自己提供的表中。这就是为什么要在两个数据结构之间提供同步服务的原因。因此如果手动添加一个用户，需要是使用DotNetNuke自带的方法，如程序所示。
DotNetNuke4.0完全利用了ASP.NET2.0成员资格提供程序API的实现。应用程序的非典型特性在新的平台发布上构建，DotNetNuke4.0在ASP.NET2.0架构上提供了一个经过测试和证明的解决方案。这些特性演示了DotNetNuke安全框架的灵活性和可扩展性。