9

メンバーシップ機能を備えたサイトを開発する場合、ほとんどの人は.NETのSqlMembershipProvider、SqlRoleProvider、およびSqlProfileProviderを使用しますか？

それとも、多くの人が独自のプロバイダーを作成しているのでしょうか、それとも完全に独自のメンバーシップシステムを作成しているのでしょうか。

自分でロールするSQLプロバイダーの制限は何ですか？

SQLプロバイダーを拡張して追加機能を提供するのは簡単ですか？

参考までに、
Scott Guのブログでは、MicrosoftがSqlMembershipProviderのソースコードを提供しているため、最初から始めるのではなく、カスタマイズすることができます。参考までに。

4

7 に答える 7

6

Profile Provider 以外のすべてを使用します。プロファイル プロバイダーは完全にテキスト ベースであり、全文検索を行います。ユーザー ベースが大きくなるにつれて、これは非常に遅くなります。メンバーシップのユーザー ID をキーとするメンバーシップ API データベースの「独自のロール」プロファイル セクションを使用する方が、はるかに優れたソリューションであることがわかりました。

于 2009-06-25T15:18:28.693 に答える
2

派生型を使用して独自のMembershipProviderクラスをMembershipUser作成し、カスタム ユーザー スキーマをラップしたので、キャストを介して派生ユーザーの一部としてプロファイル スタイルのプロパティをどこでも使用できるようになりました。

于 2009-06-25T14:56:55.383 に答える
1

私は通常、すぐに使用できるプロバイダーを使用します。主な問題は、ユーザー全体のプロファイル属性を照会することです。たとえば、Car という名前のプロファイル属性が true であるすべてのユーザーを検索します。これは、それらが基礎となる構造に格納される方法にかかっています。

于 2009-06-25T14:38:07.060 に答える
1

私は以前に SqlMembership を使用したことがありますが、何かカスタムが必要でない限り、非常に優れています。名と姓の情報が必要だったのを覚えていますが、そのためのフィールドがないことに気付きました。最後に、拡張する代わりに、プロバイダーのコメント フィールドを使用し、そこに名前情報を追加しました。これはおそらく悪い習慣/怠惰/ハックの方法ですが、厳しい状況ではうまくいきました..

于 2009-06-25T15:04:44.527 に答える
0

カスタムクラスと組み込みの両方を使用しました。別のデータベースまたはスキーマにアクセスする必要がある場合、または追加情報が必要な場合。

レイヤーを抽象化して、ロジックレイヤーで機能し、data.common.dbprovider ビットを使用する DAL レイヤーを用意して、合理的に一般的なものにしました。

于 2009-06-25T19:06:00.480 に答える
0

理論的には良いように思えますが、多くの抽象ラッパーを作成せずに単体テストを行う場合、チャンスではありません。

于 2009-06-25T14:45:15.453 に答える
0

基本的なユーザー サポート (ロール、プロファイルなど) のみが必要な場合は、既定のプロバイダーが最適です。

さらにカスタマイズされたサポート ([Oracle など] の既定のプロバイダーでサポートされていないデータベース内のデータ ストレージ、既存のデータベース上のプロバイダー、大幅にカスタマイズされたスキーマ) が必要な場合は、独自のプロバイダーを展開する必要があります。

私の場合、現在のサイトでは基本的な役割のサポート (および最小限のプロファイルのサポート) のみが必要だったので、既定のプロバイダーを使用しました。

于 2009-06-25T14:45:27.200 に答える