私のアプリケーションでは、ユーザーを登録する必要があります。ユーザーは、管理者、クライアント、一般の3つのいずれかになります。それらには異なる属性があります（管理者は名前のみ、クライアントは会社の住所など）。デフォルトのMVCメンバーシップスキームは問題ありませんが、登録時にさらに多くの情報を登録するように拡張するにはどうすればよいですか？または、カスタムメンバーシップを使用する必要がありますか？
clientIDまたはを使用したクライアントと一般ユーザーの記録が必要generalIDです。
デフォルトのMVCメンバーシップスキームは問題ありませんが、登録時にさらに多くの情報を登録するように拡張するにはどうすればよいですか？または、カスタムメンバーシップを使用する必要がありますか？
あなた自身も含めて、あまりにも多くの人々がデフォルトのASP.NETメンバーシッププロバイダーから多くを得ると期待していると思います。顧客が勤務している会社や管理者の名前など、アプリケーション固有のものを処理するようには設計されていません。主な目的は、認証用のパスワードを保存することです。
確かに、2つのキーの認証ペアが存在できるように、パスワードをユーザー名にリンクする必要があります。ユーザー名とは異なる場合は、パスワードについてユーザーに連絡するために、ユーザーの電子メールアドレスも必要になる場合があります。ただし、メンバーシップストアにはユーザーに関する他の情報を保存しないでください。アプリケーションデータベースに保存します。
アプリケーションとメンバーシッププロバイダーの間でデータを結合するには、メンバーシッププロバイダーのUserNameまたはProviderKeyをデータベーステーブルの1つの列として使用します。明示的に関連していない2つのエンティティになります。SqlMembershipProviderをアプリケーションデータベースとは別のデータベースに実装することもできます。それらが同じデータベースにある場合でも、プロバイダーテーブルとアプリケーションテーブルの間に外部キーを持たないようにします。これは、あなたが所有しているものと、メンバーシッププロバイダーに「アウトソーシング」しているものとの間の水を濁らせます。
最終的に、ユーザーの2つの物理的に分離された表現になります。1つはMembershipProviderで、これにはユーザーのパスワードが含まれています。もう1つはアプリケーションで、他のビジネス固有の詳細が含まれています。この2つは、アプリケーション内でのみ論理的に関連付けられています。メンバーシップAPIを使用してユーザーを認証すると、そのUserNameおよび/prProviderKeyがアプリケーションで使用できるようになります。次に、そのデータを使用してアプリデータベースにクエリを実行し、追加の詳細を取得できます。clientIDこれは、またはgeneralIDあなたが言及したようなものを置くかもしれない場所です。
System.Web.Security.Member * APIを見ると、これにより状況がより明確になるはずです。これは、ユーザーをパスワードやパスワードのリセットに関連するその他の情報（電子メールアドレス、質問と回答など）に関連付けることで非常にうまく機能します。したがって、パスワードプロバイダーのみをアウトソーシングし、アプリケーションに依存して重要な処理を実行します。
デフォルトのプロファイルプロバイダーをカスタマイズすることも、独自のプロファイルプロバイダーを作成することもできます...このリファレンスに従って くださいhttp://msdn.microsoft.com/en-us/library/8zs47k7y
web.configのプロファイルに新しいプロパティを追加することもできます
独自のメンバーシップロールを作成することを強くお勧めします。それは非常に単純であり、独自の実装を持つ柔軟性に勝るものはありません。
これは私がしばらく前に作ったビデオで、これを達成する方法を段階的に示しています。
http://www.youtube.com/watch?v=BsxUsyMSGeA
その要点は、独自のAuthorizeAttributeを作成し、独自のロールを作成することです。途中で各コントローラーまたは個々のアクションメソッドを保護します。
このアプローチの1つの欠点は、ユーザーがシステムでどの役割を持っているかを判断できるが、役割がシステムで何を実行できるかは判断できないことです。それは理にかなっていますか？
実行時にロールが実行できることを編集する必要がある場合は、他の選択肢があります。