我创建了一个使用 DotNetNuke.Security.Membership.MembershipProvider 作为基础的自定义 MembershipProvider。在我们的实施中，CRM 系统存储能够连接到我们任何网站的用户的所有联系数据，因此不会实施 CreateUser 和 DeleteUser 等功能。 MembershpProvider 仅处理身份验证、成员资格并返回带有 CRM 系统数据的 UserInfo 对象。
这个效果很好。
我遇到的问题是 PersonalizationController。我们的 CRM 系统存储有关用户/联系人的信息，但不存储有关用户的个性化设置的信息。我希望 DNN 继续存储 PersonalizationController / PersonalizationModule 中定义的个性化设置（例如，在配置文件表中）。问题是，当 DataProvider 调用 LoadProfile() 存储过程时，更新会失败，因为 Profile 表具有与其关联的约束，要求 UserId 已添加到 User 表中。我可以修改这个外键关系，但这不是一个好的架构。
所以，问题是：在这种情况下，什么是好的架构选择？
MembershipProvider 和 DataProvider 遵循 Provider Model，因此可以替换它们，但我不想替换 DataProvider。 PersonalizationController 不遵循 Provider 模型，因此不能轻易替换。更新存储过程或外键可能会导致升级问题（或至少使多年后的调试变得困难/需要良好的文档）。同样，更改源代码（我可以简单地更新 PersonalizationController，行 DataProvider.Instance().AddProfile(userId, PortalId); 并调用首先将用户添加到 Users 表（这应该是不必要的 - 是的，我明白用户和 aspnet_Users 表之间的区别，所以理论上，添加用户记录应该没问题，尽管仅仅因为外键而显得多余，我也可以通过插入用户表来更新 MembershipProvider - 这是我的方向。我目前正在考虑（虽然我真的不想）。
关于如何使用提供者模型替换 PersonalizationController 有什么想法吗？或者我还能如何最大限度地减少升级或管理问题？我真的在尝试构建一个系统，我们可以随时全新安装 DNN，只需在其上安装所有模块/提供程序/皮肤并复制现有系统（当然没有内容）。
在这种情况下推荐的方式/推荐的架构是什么？
提前致谢。
格雷格
将 UserID 保留在 DNN 数据库中是否有意义，以便您可以利用许多不同模块在 Users 表上可能拥有的所有键。如果您没有用户 ID，您很可能会遇到模块问题。
DNN 的 AD 提供商创建 DNN 用户，并将这些用户与 AD 用户进行匹配，以解决此问题。