8

そこで、ASP.NET MVC Web サイトを作成しています。

多くのフィールドを持つかなり複雑なユーザー サインアップ ページがあります。私の質問は、これをどこに保持すればよいですか? メンバーシップ プロバイダー ツールによって作成されたユーザー テーブルにはこれらの列が含まれていないため、各ユーザーに関するこの追加情報を保存するためのベスト プラクティスについて混乱しています。

これは、プロファイル プロバイダーの出番ですか? それらはどのように機能しますか？そうでない場合、MembershipProvider テーブルの在庫列に提供されていない追加のユーザーの詳細を保持して保存するには、どうすればよいでしょうか?

これがどのように処理されるか、必要なときにこれらの追加のユーザー詳細にアクセスする方法、このすべての情報を使用して新しいユーザーを作成する方法などに関するリソースを教えてください。

4

4 に答える 4

3

ここで、ASP.NET プロファイル プロバイダーの出番です。これを使用して、ユーザーに関して必要なプロファイル情報を格納できます。必要なのは、必要なフィールドを web.config ファイルに追加することだけです。web.config ファイルでプロファイル フィールドを構成する方法に関する MSDN リンク。この記事を要約すると、格納する名前と型の値を profile 要素のプロパティ ノードに追加するだけです。次に例を示します。

<profile enabled="true">
  <properties>
    <add name="Name" />
    <group name="Address">
      <add name="Street" />
      <add name="City" />
      <add name="Zip" type="System.Int32" />
    </group>
  </properties>
</profile>

ASP.NET Webforms では、カスタム プロファイル プロパティを参照する厳密に型指定されたプロファイル クラスが Visual Studio によって自動的に作成されます。MVC では、これは起こりません。ユーザーのプロファイル情報を参照するには、HttpContext.Profile["PropertyName"] を呼び出すだけです。例：

HttpContext.Profile["Name"] = name;
HttpContext.Profile.GetProfileGroup("Address")["Zip"] = zip;

編集: Andy が指摘したように、これらのプロパティに対してクエリを実行する場合、既定の SqlProfileProvider を使用するのはあまり良くありません。彼の言うことは完全に正しいし、おそらく私は最初にこの制限に注意するべきだった. この制限が存在するのは、SqlProfileProvider がすべてのプロファイル データを PropertyNames と PropertyValuesString/PropertyValuesBinary の 3 つの列に格納するためです。すべてのキーは PropertyNames フィールドに格納され、文字列として格納できる値は PropertyValuesString フィールドに格納されます。つまり、"Select * from aspnet_Profile where Age > 10" のようなクエリを実行するのは非常に困難です。

于 2009-07-16T21:27:43.853 に答える
3

ベストプラクティスがあるかどうかはよくわかりません。それは、情報をどのように使用したいかによって異なります。

まず、メンバーシップとプロフィールは 2 つの別個のものであることを認識する必要があります。ASP.NET のメンバーシップ、プロファイル、およびロール機能は、複数のサイト/アプリケーションにサービスを提供するサービスとして使用するように設計されています。

これらの関係のスキーマを見ると、ユーザーはシステムに固有ですが、ユーザーはアプリケーション間で共有できることがわかります。つまり、プロファイル情報はアプリケーション間でも共有されます。メンバーシップは、実際にはユーザーとアプリケーションとの関連付けであり、その特定のアプリケーションとの関係に関する情報 (パスワード、パスワード Q&A など) が含まれています。

Ryan が提案したようにプロファイル プロバイダーを使用できますが、1) プロファイル メトリックを収集する必要がある場合、その情報は簡単に照会されず、2) メンバーシップ/プロファイル サービスのすべてのコンシューマー間で共有されます。ただし、必要に応じて拡張できます。

Gortok が提案したようにメンバーシップ プロバイダーを拡張することができ、その情報はアプリケーションに関連しますが、既存のストアド プロシージャまたはテーブルをインターフェイスまたは変更する方法で変更することによって、サービスの既存のコンシューマーを壊さないようにする必要があります。意図。

もう 1 つのオプションは、それをサービスとして扱い、asp.net SQL プロバイダーからのユーザー ID を使用して独自のプロファイル実装を参照して、この情報を独自に追跡することです。

Rolla の 4 Guysに、メンバーシップ、プロファイル、およびロールに関する優れたシリーズ (16 部) があります。これを読むことをお勧めします。次に、すべての可動部分に慣れたら、知識に基づいて最適な場所を決定してください。作成しようとしているプロファイル情報を保存する方法と最適な構造化方法。

于 2009-07-16T22:17:07.887 に答える