2

users、books、およびの 3 つのテーブルがあるとしusers_booksます。

ビューの 1 つで、現在のユーザーがアクセスできるすべての書籍のリストを表示したいと考えています。ユーザーとブックに一致する行が に存在する場合、ユーザーはブックにアクセスできますusers_books。

これを達成するには、(少なくとも) 2 つの方法があります。

  • モデルの私のfetchAll()メソッドでは、テーブルで何らかの種類の a を実行します。booksjoinusers_books
  • ACL プラグインでは、まずすべての本からリソースを作成します。次に、すべてのユーザーからロールを作成します。次に、テーブルに基づいて各リソースへのユーザー アクセスを許可または拒否しusers_booksます。最後に、モデルのfetchAll()メソッドで、現在のユーザーをロールとして使用して、見つけた各書籍を呼び出します。booksisAllowed()

アプリケーションの他の場所で Acl を使用できるため、最後のオプションが最適だと思います。これにより、重複したアクセス チェックを実行する必要がなくなります。

何を提案しますか？

4

2 に答える 2

1

getBooksByUser(User $user) のような add メソッドを使用してリポジトリ クラスに finder メソッドを作成し、書籍オブジェクトのコレクションを返すことで、モデルからデータベース アクセス コードを分離します。

あなたが説明したものからACLが必要かどうかは完全にはわかりません。私は間違っているかもしれません。

于 2011-05-24T22:24:45.103 に答える
1

私はそれをすべてデータベースにプッシュします：

  1. JOIN を介してデータベースで実行すると、PHP でフィルタリングするよりもはるかに高速になります。
  2. データベースでこれを行うと、必要以上のデータを取得するなどのフープをジャンプすることなく、物事を適切にページ付けできます (そして、あまりにも多くのデータを捨ててしまう場合は、さらに多くのデータを取得します)。

ACL を管理するために採用できる 2 つの大まかな戦略を考えることができます。

次のような単一のテーブル ソートを使用して、データベースに明示的な ACL を設定できます。

  • id: 問題の物 (本、写真など) の ID。
  • id_type: ID が由来するタイプまたはテーブル。
  • user: モノを見ることができるユーザー。

( id, id_type) のペアは、データベースのサニティ チェックに使用できる疑似 FKid_typeを提供し、ACL のタイプ固有の部分と対話し、SQL スニペットを追加するために必要な接着剤を提供するためにクラスを選択するために使用できます。 ACL テーブルを適切に結合するためのクエリ。

または、命名規則を使用して、ACL が必要な各テーブルに ACL サイドカー テーブルをアタッチすることもできます。tableの場合、次のような列をt持つテーブルを作成できます。t_acl

  • id: 内のモノの ID t(整合性のための実際の外部キーを使用)。
  • user: ユーザーはモノを見ることができます。

次に、ベース テーブル名を指定して SQL を調整できる単一の ACL クラスを作成できます。

最初のアプローチの主な利点は、すべてに対して 1 つの ACL ストアがあるため、「ユーザー X は何を見ることができるか?」などの質問に簡単に答えられることです。2 番目のアプローチの主な利点は、実際の参照整合性と、すべてを結合するための (命名規則による) 少ないコードを実現できることです。

うまくいけば、上記はあなたの考えを助けるでしょう。

于 2011-05-24T22:17:44.527 に答える