データベースからロールベースのコンテンツを取得するオプション

Question

データベースからサービスレイヤーへのロールベースのコンテンツ（複数のオブジェクトが1つのオブジェクトになる）を必要としています。各コンテンツへのアクセスは、ユーザーが持つ役割によって異なります。ユーザーロールに作品へのアクセス権がない場合、そのロールは空になります。これは巨大なアプリケーションではなく、ロールに基づいていくつかのコンテンツを公開するWebサービスメソッドです。

私は3つの方法でこれを行うことができます。

1）ユーザーロールに基づいて、各コンテンツに対してデータベース呼び出しを行います。

利点 - コード内で役割が管理され、ビジネスロジック（？）がコード内にとどまるのを助けます。必要なデータのみを返します。

短所 - 複数のdb呼び出し。新しい役割が追加されると、コードを修正する必要があります。 （実際に複雑なビジネスロジックが使用されていない限り）

2） 1つのdbコールを作成し、すべてのコンテンツを別々の結果セットとして返します。セットをループし、ユーザーの役割に基づいて部分を取得します。

プロ - シングルDBコール。ロールはコード内で管理されます。

新しい役割のためにコードを修正する必要があります。余分なデータは必要ないかもしれませんが、戻されます。これらの不要なクエリは数秒を追加する可能性があります。

3） dbにロールを送信し、ロールアクセスに基づいて各ピースを取得します。

プロ - シングルDBコール。必要なものだけを返します。ストアドプロシージャだけを変更する必要があるため、新しいロールのコードを変更する必要はありません。

データベースの短所ですか？

---

＃3>＃2>＃1と思われます。 （オーバーライド>がより良いことを意味します）

どのアプローチが優れているかについての洞察はありますか？

更新 - いくつかのコメントに基づいて、いくつかの詳細が以下にあります。

ユーザロールは別のシステムから取得されます。 ＃3はそれをdbに理想的に渡し、dbの原語では、user_role = "admin"のようにデータを返し、すべての部分を取得し、 "editor"のコンテンツ部分1,3,5を取得します。ロール管理がdb内で行われる大きなアプリケーションではありません。いくつかの企業のデータを公開するWebサービスメソッドです。

明らかに、このモデルをアプリケーション全体のロール管理に使用することはできません。しかし、このシナリオのようなメソッド・レベルのアクセス制御では、＃3が最善の方法だと思います。役割はコンテンツが存在する場所以外のシステムから来るため、異なるコンテンツ部分へのアクセスを制御するロジックがどこかに存在しなければなりません。この特定のシナリオでは、データベースは、保守可能でスケーラブルで、面倒なソリューションを提供するのに適しています。恐らく、コンテンツDBにルックアップテーブルを作成して、役割とコンテンツのアクセス権を保持して、ロジックを実行するのではなく、「データ」と「ロジック」分離の感覚を与えます。

＃3に対して誰も有効なケースを考えることができない場合、私はそれを進めると思います。

Answer 1

私は常にオプション3を選び、それをデータベース自体に強制します。

セキュリティは、多くの理由で実際のデータ自体に最も近い点で最もよく処理されます。このように見てください。追加のアプリケーションをデータベースモデルとは異なる言語で追加するのが一般的です。これが起こると、すべてのロール処理コードを複製する必要があります。

または、アプリケーションがハッキング中に完全にバイパスされているとします。データベースはそれでもセキュリティを強化する必要があります。

最後に、人々はデータから「ビジネスロジック」を分離するのが好きですが、現実には、ほとんどのデータは前記のロジックなしで意味を持ちません。さらに「セキュリティロジック」は、通常の「ビジネスロジック」と同じではありません。あなたとあなたのクライアントを守るのはそこにあります。しかしそれは私の0.02ドルです。

---

あなたの他のオプションを見て：

2）あなたは、クライアントにあまりにも多くのデータを送信しています。これはセキュリティとパフォーマンスの両方ではありません。あなたのアプリがデータリクエストをしていない場合はどうなりますか？あなたのアプリがユーザーにあまりにも多くを示すわずかなバグを持っていたら？

1および2）どちらも、軽微なロジック変更（上の神話バグの修正など）でも再デプロイする必要があります。これは望ましくないかもしれません。個人的には、コードを再デプロイするよりも、ストアドプロシージャを少し調整する方が好きです。十分な規模のプロジェクトでは、すべてが展開されていることを正確に知ることは難しく、一般的に問題の可能性が高いだけです。あなたの追加情報に基づいて

UPDATE

、私はまだ＃3にこだわっ示唆しています。

Answer 2

年に何人の新しい役職が予想されますか？ロールが少ない場合は、コードが単純になる場合は、すべてをコードに貼り付けます。多くの場合、オプション＃3を使用してください。

複数の呼び出しを本当に嫌うなら、いつでもSELECT ... UNIONを実行するか、単純なストアドプロシージャに検索を延期することができます。

また、無数のRBACフレームワークのうちの1つを取得し、問題を処理してみましょう。

Answer 3

データベースの構造によって異なります。あなたは、データベースにアクセス権を管理することができる場合

、あなたは絶対にない「ビジネスロジックは、データベース内に」ある

その後

Content Table 
ContentId Content 

Role Table 
RoleID  RoleName 

ContentAccess Table 
ContentID RoleID 

は、クエリパラメータとしての役割を渡すの線に沿ってテーブルのデザインを持っているかもしれません。 「content」および「contentaccess」テーブルに参加するクエリを作成して、現在のユーザーのロールのContentAccessに一致するレコードがあるコンテンツテーブルの行を取得することは明らかです。

アプリケーションでコードを使用して、特定のコンテンツをユーザーに表示することが許可されているかどうかを判断する場合、機能しません。これの最も厄介な例は"if user_role = "admin" then get all content, if user_role = "editor" get items 1, 3 and 55 "です。私はこれが本当に保守可能なデザインではないと主張したいと思いますが、アプリケーションはそれほど大きくないと言いますから、それは大きな問題ではないかもしれません。

理想的には、保守性を要件としているため、アプリケーションに「コードではなくデータとしてアクセス権を管理する」ことを理想的に考えています。

そうしたくない場合は、オプション1を使用します。複数の異なるクエリではなく、「in」クエリにそれを絞り込むことができます。したがって、ユーザロールがコンテンツを見ることができるかどうかを決定するロジックを実行し、"select * from content where content_id in (1, 3, 55)"の行に沿ってクエリを実行します。

異なる人々は、ストアドプロシージャについて異なる感情を持っています。私の見解では、ストアドプロシージャを使用することでしか満たされていない実績のある測定可能なパフォーマンス要件がない限り、ストアドプロシージャの使用を避けることです。テストは難しく、デバッグは難しいですが、Transact SQLとC＃（あるいは何か）の両方で優れている開発者を見つけるのは比較的まれで、バージョン管理などは通常は苦労します。