8

asp.net 4 で新しいアプリケーションを設計する MS SQL データベース内の自分のデータと共に MS SQL メンバーシップ API を使用する方法を決定する必要があります。まず、プロファイル プロバイダーがサポートするよりも柔軟な方法で、ユーザー プロファイル データを保存してアクセスする必要があります。次に、他のユーザー関連情報 (注文など) をリンクしたいと思います。

aspnetdb テーブルをどこに (別のデータベースに、またはデータと同じデータベースに) 保存するかに関係なく、データの同期を維持する方法の問題は残ります。

調査の結果、次の関連オプションが表示されます。
1. asp_Users からの外部キー UserId (このチュートリアルで推奨)。
2. 外部キーを使用しないトランザクション (ここで推奨)。
3. 外部キーなし - カスタマイズされた AccountController を使用します (それが何であれ、ここで提案されています)。
4. メンバーシップ UserId (uid) をカスタム UserId (int) にリンクする追加のテーブル。
5. ...

一方では、最初のソリューションが非常に簡単で、公式の asp.net チュートリアルで提案されているので気に入っています。

一方、反対派は、外部キーを使用すると、懸念事項を分離し、交換可能であると考えられているプロバイダーの一般的な考え方が崩れることに非常に合理的に注意しています。しかし残念なことに、実装の詳細にはあまり触れていないため、関連性と実装の容易さの観点からこれらの提案を評価するのは簡単ではありません。

では、これにアプローチするための最良の選択肢は何ですか? さらに、実装はどのようになりますか? 追加の ADO.NET や LINQ などのコードを使用するだけで十分でしょうか、それともカスタム メンバーシップやプロファイル プロバイダーを実装する価値がありますか?

前もって感謝します。

4

2 に答える 2

7

1 つ目は、最も単純なアプローチです。ユーザーの GUID を外部キーとして関連テーブルに追加します (fe Ordered_by)。懸念の分離がどこで壊れているのかわかりません。注文レコードをデータベースに保持したい場合は、注文したユーザーも保持する必要があります。これは完全に理にかなっています。

現在のアプリケーションでは、オプション 4 をうまく使用しています。主キーとして、外部キーとして fiUser (の GUID ) を持つテーブルaspnet_UserIDを作成しました。モデルは次のとおりです。idUser intaspnet_Users

データ・モデル

(注: aspnet_regsql.exeによって作成されUserた標準テーブルであり、すべての Guid を int-ID にマップするカスタム テーブルです)aspnet_Usersaspnet_UserId

今、私はidUserすべての関連するテーブル (Order-Table など) に my as FK のみを格納しています。これには、ストレージが少なくなり、ユーザー ID が読みやすくなるという利点があります (GUID を思い出すことはできませんでした)。たぶん、この「ラッパーテーブル」でもう少し分離されているかもしれませんが、それは私の主な意図ではありませんでした.

動作を制御したい場合は、外部キーの削除規則を変更できます。Cascade削除しようとしているユーザーによって注文されたすべての注文を削除する場合は に設定し、この注文を保持する場合no Actionは に設定します。

「プロファイルプロバイダーがサポートするよりも柔軟な方法でユーザープロファイルデータを保存およびアクセスする必要がある」という意味に言及していないため、プロファイルの質問に代わるものを提案することはできません.

于 2011-06-30T09:19:14.443 に答える
1

ASP.NET が提供するスキーマを使用する代わりに、必要に応じてテーブル/データを使用する独自のカスタム メンバーシップ プロバイダーを作成することを検討する必要があります。

カスタム プロバイダーの記述については、この MSDn サンプル ( schema、code ) を参照してください。このサンプルでは、​​OLEDB を使用してデータベースにアクセスします。さらに別のサンプルがここにあります。これは、Active Directory をストアとして使用します。

于 2011-06-30T09:18:36.640 に答える