MembershipProvider、MembershipUser、RoleProviderなどに基づいてカスタムメンバーシップを作成するときに、かなりの数の壁にぶつかり、障害が発生しています。
私たちにはいくつかの興味深い要件があり、メンバーシッププロバイダーはそれらを達成するのにあまり役立っていないようです。
- ユーザーは複数のログインを持つことができます。
- ユーザーは直接ユーザー名を持っていません（ただし、ユーザー名を持つログインを持っている場合があります）。
- ユーザーには1つの一意の参照があります（現在、自動インクリメントの主キー）。
これを実装するために、2つのテーブルがあります。ログインと1対多の関係を持つユーザー。
これは事実上、（仮想の世界では）Active Directoryアカウントを介して（可能な場合）自動的に、またはOpenIDまたはユーザー名/パスワードの組み合わせを介してログインできるユーザーがいることを意味します。ADアカウントを持っていない可能性のあるユーザーもいます。
私は当初、以下を作成してメンバーシップクラスの転用を試みました。-CustomMembershipProvider-CustomMembershipUser-CustomRolesProvider
しかし、それに対する私のすべての戦いは、私に黒い目と打撲傷を与えました、それは本当に、本当にユーザー名を望んでいます！
私はこれを最善の方法で行ったことがありますか？ストレッチから始めて、何も継承しないようにする必要がありますか？IProviderクラスに基づく必要がありますか？それとも、GenericPrincipalクラスとGenericIdentityクラスですか？それとも、MembershipProviderで何かが足りないだけですか？
すぐに使えるメンバーシップの場合と同じように、エンドプログラミングエクスペリエンスを簡単に保ちたいと思っています。
Membership.GetCurrentUser();
そして、単純ではないエンドコーダーエクスペリエンスを避けてください...