私は、.NET MVC でカスタム プロファイル プロバイダーを実行する方法について調査を行ってきました。かなり複雑なようです。他の代替手段はありますか？そして、これが私の主な関心事です。なぜ、わざわざ顧客プロファイルプロバイダーを使用するのでしょうか? ユーザーに関する追加情報が必要な場合は、外部キーとして userId または userName を持つ aspnet_Users との OneToOne 関係を持つ別のテーブルを作成してみませんか?
どうか明らかにしてください。ユーザー プロファイル機能を実装しようとしていますが、間違った道をたどりたくありません。
ありがとうございます
(これがカスタム プロファイル プロバイダーについて話すのに役立つかどうかはわかりません..誤解されていない限り...)
IMO、あなたが何をしても.. （焼き込み）は絶対に避けてください！それはあまりにも設計されすぎており、鈍いスプーンで自分の目を刺したくなるでしょう:(ASP.NET Membership
私を信じて。それを避けてください。
理由: ASP .NET MVC アプリケーションには組み込みのメンバーシップ プロバイダーを使用する必要がありますか?
それで..代わりに何ができますか？
独自のユーザー名/パスワードをロールして、組み込みの を活用するのはとても簡単Forms Authenticationです。私自身、パスワードを自分のデータベースに保存するのは好きではないので、認証メカニズムとして Facebook、Twitter、または OAuth を使用することを好みます。カスタム ユーザー クラス。
個人が認証されたときに Forms Auth が作成する Cookie にもう少し情報を保存したいので、独自のカスタム IPrincipal と IIdentityも作成します。これにより、コントローラー内のコードをよりクリーンでシンプルに保つことができます。
たとえば、認証された人の userId を暗号化された Cookie に保存します。(デフォルトのオプションは、 a のみを保存することですName)。他にも 1 つまたは 2 つのものを保管しています。このようにして、ユーザーデータを取得したり、このがらくたをセッションに保存したりするために、常にDBにアクセスする必要はありません。
独自のロールを使用すると、追加のメタデータ (誕生日? 母の旧姓? 社会保障番号 (ジョーク)) を作成し、その追加のプロファイル データを取得できます。同じテーブル？余分なテーブル？誰が気にする...それは後で行う決定です（そして解決するのは簡単です）。モデルを正しくしましょう、IMO :) 次に、モデルをロックダウンすると、何が必要で何がオプションかがわかります..そして、DBの決定を下すことができます。
TLDR? ?
IPrincipalをIIdentidy本当に揺るがしてください.GL HF で、鈍いスプーンで自分の目を刺さないでください。
