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