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