DotNetNuke.Security.Membership.MembershipProvider をベースとして使用するカスタム MembershipProvider を作成しました。当社の実装では、CRM システムは、当社の Web サイトに接続できるユーザーのすべての連絡先データを保存するため、CreateUser や DeleteUser などの機能は実装されていません。MembershpProvider は、認証、メンバーシップ、および CRM システムのデータを含む UserInfo オブジェクトを返すことのみを処理します。
これはうまくいきます。
私が直面している問題は、PersonalizationController にあります。当社の CRM システムは、ユーザー/連絡先に関する情報を保存しますが、ユーザーのパーソナライズ設定に関する情報は保存しません。DNN が、PersonalizationController / PersonalizationModule (たとえば、プロファイル テーブル) で定義されているように、パーソナライゼーション設定を引き続き保存することを希望します。問題は、LoadProfile() ストアド プロシージャが DataProvider によって呼び出されると、更新に失敗することです。プロファイル テーブルには、UserId が既に User テーブルに追加されている必要があるという制約が関連付けられているためです。この外部キーの関係を変更することはできますが、それは適切なアーキテクチャではありません。
問題は、この状況で適切なアーキテクチャの選択は何かということです。
MembershipProvider と DataProvider は Provider Model に従っているため、置き換えることができますが、DataProvider を置き換えたくありません。PersonalizationController はプロバイダー モデルに従っていないため、簡単に置き換えることはできません。ストアド プロシージャまたは外部キーを更新すると、アップグレードの問題が発生する可能性があります (または、少なくとも数年後のデバッグが困難になり、適切なドキュメントが必要になります)。同様に、ソース コードを変更すると (PersonalizationController の行 DataProvider.Instance().AddProfile(userId, portalId); を更新して、最初にユーザーを Users テーブルに追加する呼び出しを行うだけです (不要なはずです。はい、わかりました)。 Users テーブルと aspnet_Users テーブルの違い。したがって、理論的には、User レコードを追加しても問題ありませんが、単に外部キーが原因で不要になります。
プロバイダー モデルを使用して PersonalizationController を置き換える方法はありますか? または、今後のアップグレードや管理の問題を最小限に抑えるにはどうすればよいでしょうか? 私は本当に、いつでも DNN を新しくインストールして、すべてのモジュール / プロバイダー / スキンをその上にインストールし、既存のシステムを (もちろんコンテンツなしで) 複製できるシステムを構築しようとしています。
この状況で推奨される方法/推奨されるアーキテクチャは何ですか?
前もって感謝します。
グレッグ