DotNetNuke PersonalizationController架構/替換

Question

我創建了一個使用DotNetNuke.Security.Membership.MembershipProvider作爲基礎的自定義MembershipProvider。在我們的實施中，CRM系統爲能夠連接到我們任何網站的用戶存儲所有聯繫人數據，因此不實施CreateUser和DeleteUser等功能。 MembershpProvider僅處理身份驗證，成員身份並返回一個UserInfo對象與CRM系統的數據。

這工作正常。

我遇到的問題是PersonalizationController。我們的CRM系統存儲關於用戶/聯繫人的信息，但不涉及用戶的個性化設置。我希望DNN繼續存儲PersonalizationController/PersonalizationModule中定義的個性化設置（例如，在配置文件表中）。問題是，當DataProvider調用LoadProfile（）存儲過程時，它會在更新時失敗，因爲Profile表具有與之關聯的約束，要求將UserId添加到User表中。我可以修改這個外鍵關係，但這不會是一個好的體系結構。

所以，問題是：在這種情況下會有什麼好的建築選擇？

MembershipProvider和DataProvider遵循提供者模型，因此可以替換它們，但我不想替換DataProvider。 PersonalizationController不遵循提供者模型，因此不能輕易替換。更新存儲過程或外鍵可能會導致升級問題（或者至少使調試年後很難/需要良好的文檔）。同樣在更改源代碼（我可以簡單地更新PersonalizationController，行DataProvider.Instance（）。AddProfile（userId，portalId）;通過調用首先將用戶添加到用戶表（這應該是不必要的 - 是的，我明白用戶和aspnet_Users表之間的區別，理論上講，添加一個用戶記錄應該是可以的，儘管這僅僅是因爲一個外鍵的原因，我也可以通過插入用戶表來更新MembershipProvider - 這是我的方向，我正在考慮如何使用提供者模型來取代PersonalizationController？或者我怎麼才能最大限度地降低升級或管理問題？我真的很想要（雖然我不是很想）

試圖建立一個系統，我們可以隨時安裝DNN新鮮，並簡單地安裝我們所有的模塊/供應商/外殼它並複製現有的系統（當然沒有內容）。

在這種情況下推薦的方式/推薦架構是什麼？

在此先感謝。

格雷格

Answer 1

會是有意義的保持用戶名在DNN數據庫中，這樣就可以利用所有許多不同的模塊可以對用戶表的鍵。如果你沒有用戶標識，很可能你會遇到模塊問題。

DNN的AD提供程序創建DNN用戶，並將其與AD用戶進行匹配以解決此問題。