2

ASP.NET MVC3アプリケーションには、ユーザー、ロール、およびエンティティがあります。ユーザーロールはエンティティにアクセスできます。では、ユーザーとロールをデータベースに保存する場合、次のうちどれが適切なアプローチですか？

  1. ユーザーリストをエンティティテーブルに保存するには

  2. ユーザーテーブルのエンティティID。

将来的にはエンティティ数が1000,10000に増える可能性があるので、パフォーマンスの側面も考慮したいと思います。

4

2 に答える 2

1

役割と実体の関係は多対多だと思います。1つのロールは0個以上のエンティティを持つことができ、1つのエンティティは0個以上のロールに属することができます。したがって、2列のテーブルを格納するための3番目のテーブルを作成しRoleId、EntityID

サンプルデータは次のようになります

ROLE_ID        ENTITY_ID
-----------------------------------
1              144
1              146
2              194
4              14
4              194
于 2012-11-05T12:15:33.277 に答える
0

アプリケーションに必要な制御の粒度に応じて、現在.NETFramework4.5の一部であるWindowsIdentityFoundation（WIF）で使用されているモデルを検討することをお勧めします。これはクレームベースのアーキテクチャであり、エンティティと呼んでいるものに使用される用語はリソースです。モデルと異なるのは、操作の概念もあることです。リソースには多くの操作を含めることができ、一般的な操作は読み取り、書き込み、実行などです。ここで、より細かい制御が必要になります。

したがって、この場合、特定のリソースの操作には多くの役割があり、役割には多くの操作があり、この多対多の関係をマップするために別のテーブルが必要になります。オブジェクトIDとしての 役割と操作の主キーにintを使用すると、パフォーマンスが向上します。ユーザーは多くのロールを持つことができ、ロールには多くのユーザーがいるため、この多対多の関係を管理するには、もう一度別のテーブルが必要になります。

したがって、質問1の答えは、ユーザーリストをエンティティテーブルに保存しないことです。別のUserテーブルがあり、Users-To-Rolesのテーブルにマップされ、Rolesにマップされ、Roles-To-Operationsにマップされ、Operationsのテーブルにマップされ、 Resourcesのテーブルにマップされます。操作の粒度が必要ない場合は、そのテーブルを削除し、別のテーブルを介してロールをリソースにマップして、この多対多の関係を処理します。

質問2の答えは「いいえ」です。ユーザーテーブルにエンティティ（リソース）IDがありません。ユーザーは、上記の関係を介してリソースにマップされます。

このモデルとクレームベースのアーキテクチャの全範囲を使用するための最良のアプローチは、 AuthorizeAttributeを使用してメソッドにロールを割り当てないことです。これは、過去に通常行われていた方法です。代わりに、リソースと操作をメソッドに割り当てて、セキュリティポリシーをアプリケーションから切り離します。このアプローチのモデルについては、ClaimsPrincipalPermissionAttributeを参照してください。このアプローチを使用する独自のカスタムAuthorizeAttributeを作成できます。

于 2012-11-05T14:36:39.273 に答える