私は PostgreSQL に対して動作するオープンソースのプロファイル プロバイダーを作成しようとしてきました (利用可能な他のプロジェクトの制限と不完全さに不満を感じていました) が、人々がそれを使用する方法のドキュメントと例は驚くほどまばらでした。 . の SO タグでさえ、asp.net-profiles100 を少し超える質問が関連付けられています。
私がそれを機能させるために掘り下げるほど、それはますます実用的ではないように見えます。追加された価値は、関連する複雑さを正当化するようには見えません。さらに、余分な作業をしなくても、限られた範囲の Web プロジェクトでしか機能しないようです。
これは一般的なテクノロジではなく、より堅牢なユーザー ベースの情報セットを保持するためのより良い方法があるという結論に導かれているように感じます。
これに対する私の見方は根本的に間違っていますか？これは広く使われていますか？価値がほとんどないように見えるため、プロファイルプロバイダーを放棄するところです。
私は常に ASP .NET メンバーシップ プロバイダーを避け、カスタム実装を支持してきましたIPrincipal。理由は 1 つだけです。それが提供するすぐに使える機能を必要としたことはほとんどありません。
カスタム実装とは、 の独自の実装を作成することを意味しますMembershipProvider。私が実装したことのない他のメソッドの中には、RequiresQuestionAndAnswerや などの驚異が含まれていますMaxInvalidPasswordAttempts。必要のない実装が強制され、適切に完了するまでにより多くの時間がかかります。
確かに、ごまかして、NotImplementedException特に気にしないメソッドを挿入することはできますが、実稼働システムでそれを快適に行える正しい心のあるコーダーがいるでしょうか? :D
私はマイクロソフトのものの多くが本当に好きですが、私の経験では、彼らの「すぐに使える」ソリューションの多くはバニラモードで問題ありませんが、人里離れた道を進むと車輪が外れる傾向があります. したがって、少しチェリーピッキングが必要です。私のアドバイス？これをつるに残します。
いいえ、主にあなたが言及した理由により、asp.netのプロファイルシステムは広く使用されていません。多くの人にとっては役に立たないだけです。
最も簡単な解決策は、アプリでプロファイル テーブルを作成し、それをメンバーシップ システムの ProviderUserkey に入力することです。