カスタム メンバーシップ プロバイダーを使用して連絡先と拡張データをユーザー データベースに追加してはいけない理由はありますか?
ユーザー データとメンバーシップ データ用に個別の 1 対 1 のテーブルを保持する利点は何ですか? 私が理解しているように、一般的な方法は別々のテーブルを保持することです。ユーザーが SQL ステートメントをシンプルに保ち、メンバーシップ プロバイダーのカスタム コードを保持するために、テーブルを 1 つ用意する方がよいと考えています。
2 に答える
2
メンバーシップの背後にある考え方は、プラグアンドプレイの汎用メンバーシップソリューションを提供することです。SQLからActiveDirctoryに切り替えたい場合、メンバーシッププロバイダーを変更するだけで、すべてが機能します。
カスタムプロバイダーを作成している限り、好きなことを行うことができます。ただし、追加のデータをメンバーシップテーブルに取り込むには、メンバーシップインターフェイスの外部で行う必要があります（APIにはそれらのフィールドが含まれていないため）。つまり、基本的にMembershipAPIを破棄しているということです。
私のアドバイスは、a）意図したとおりにメンバーシップを使用するか、b）外に出て自分のことを完全に行うことです。メンバーシップを意図しないものに押し込もうとしないでください。
しかし、少なくともあなたが安全ですべての拠点をカバーしたいのであれば、あなた自身を書くことはあなたが最初に考えるかもしれないよりもはるかに複雑です。
于 2012-05-15T03:55:03.853 に答える
1
利点は、関心の分離です。それらを別々のテーブルに保持することにより、メンバーシップデータストアを個別にスワップアウトまたは変更できる状況になります。ただし、「柔軟性」に興奮しすぎる前に、アプリケーションの現実的な寿命を検討してください。将来的に変更が必要になる可能性と、カスタムプロバイダーを実装するための初期費用を比較検討してください。
カスタムメンバーシッププロバイダーを実装したとき、完全にカスタムの認証メカニズムを導入したいと思っていたことがよくあります。プロバイダーインターフェイスを実装した後は、プロバイダーインフラストラクチャの残りの部分を「プラグイン」することで、必ずしも多くを得ることができるとは限りません。単純なアプリの場合、私は通常、機能する最も単純で最も簡単なことを行うことをお勧めします。多くの認証システムを構築していない場合は、カスタムプロバイダーを実装するプロセスが教育的であることに気付くかもしれません。
于 2012-05-15T03:58:11.260 に答える