3

データベースを使用する Web アプリケーションを構築しています。また、オブジェクト リレーショナル マッパーを使用してデータベースにアクセスします。Web アプリケーションでの承認の 1 つの側面は、ユーザーが URL によって参照されるオブジェクトにアクセスできることです。URL には、データベース内の特定のレコードに対する一意の ID (主キーなど) が含まれています。次の例を考えてみましょう。

  • ユーザーは多くのグループに属することができ、グループは多くのユーザーを持つことができます(多対多)。
  • 調査はグループに属します(多対 1)。
  • アンケートには複数の質問がある場合があります。(多対一)。

次の URL があるとします: http://app.local/question/edit/10。これは、PK 10 で質問を編集する必要があることを意味します。ここで、ログインしているユーザーがPK 10で質問にアクセスできるかどうかを確認したいと思います。ログインしているユーザーと同じユーザーがいる場合、ログインしているユーザーは質問にアクセスできます。

これを少し一般化します。既知の多対一または多対多の関係によってレコードが別のレコードから到達可能かどうかを確認したいと考えています。そのため、多対 1 の関係がある場合 (調査と質問のように)、ユーザーが質問から調査を通じて、次にグループを通じて到達可能かどうかを確認する必要があります。グループには多対多の関係があります。そのため、ユーザーの一部 (すべてではない) がログイン ユーザーと同じかどうかを確認する必要があります。

テーブルに複数の多対 1 の関係がある場合、たとえば、次のようになります。CSSテンプレートを調査に添付でき、このテンプレートもグループに属している場合、すべての多対 1 の関係 (グループとテンプレート) からユーザーに到達できるかどうかを確認する必要があります。もちろん、同じことが複数の多対多の関係にも当てはまります。

この動作をサポートするオブジェクト関係マッパーはありますか? そして、この動作は何と呼ばれていますか?おそらく到達可能性は? Propel (PHP 用) はこの動作をサポートしていますか? この到達可能性は、次の 2 つの方法のいずれかで実行できると思います。

  • 各「親」を取得するためにクエリを実行し、多くのクエリを使用します)
  • 必要なすべてのテーブルを結合して、1 つのクエリでレコードが存在する (到達可能なユーザーがログインしているユーザーと一致する) かどうかを確認します。

さらに、ORM のこの動作はネストされたセットをサポートする必要があるため、グループにネストされたセットの動作が含まれる場合は、グループの親を介してユーザーに到達することも試行する必要があります。

この種の振る舞いは承認に限定されるべきではないと思います。オブジェクトは、別のオブジェクトに到達できるかどうかを簡単に確認できる必要があります。

到達可能性による永続性を意味するものではないことに注意してください: http://jpaobjects.sourceforge.net/m2-site/main/documentation/docbkx/html/user-guide/ch08s03.html。

または...私は単にこの承認を間違って見ているだけですか?ORMを使用したはるかに優れた別のアプローチはありますか?

4

1 に答える 1

1

これまで、Ruby on Rails (Active Record ORM を使用) でネストされたリソースを使用してこれを処理しました。http://app.local/question/10/editではなく、URI はhttp://app.local/survey/5/questions/10/editになります。

コントローラーでは、質問と調査の両方をロードします。サーベイを認証済みユーザーのグループ メンバーシップと比較することで、承認を確認します。これを設計する 1 つの方法は、このロジックを User クラスに埋め込むことです。たとえば、コントローラーにはと がquestionありますsurvey(そして、この 2 つの関係は ORM によってよく理解されています。つまりquestion.survey)。次に、 access を としてチェックすることができますuser.hasAccess?(question)。これは、比較的簡単に記述できる方法です。擬似コード:

class User < ActiveRecord::Base

  def hasAccess?(question)
    return question.group.users.include?(self)

はい、これにより舞台裏でいくつかのクエリが発生しますが、ORM が作業を行います。確実なスキーマと読みやすいコードが残っているため、私はこのようにしています。実際にパフォーマンスの問題が発生するまで最適化しないでください。

于 2012-08-06T20:03:25.163 に答える