8

私はさまざまな MVC フレームワークについて多くのチュートリアルを行ってきましたが、承認がコントローラーで行われるのは非常に一般的なようです。なんで？

私の考えでは、コントローラーは、モデル アクションの調整、リダイレクトの処理、およびエラー イベントの処理にのみ使用する必要があります。これらは、特定の要求に依存するものです。コントローラーに承認を配置すると、異なるコントローラーアクションまたは異なるコントローラーで同じモデルアクションを使用するたびに、承認を複製する必要があるようです。Auth がモデル内にある場合、データに対してアクションまたは状態の変更を実行するための一貫した要件があります。

私はグーグルで、承認はモデルまたはコントローラーの一部であるべきですか?などの他の質問を見てきました。しかし、なぜそれが受け入れられた慣習なのか、私にはよくわかりません。

モデル上のコントローラーに Authorization を配置するために欠落している特定の理由はありますか?

コメントの要点を要約するには:

  • コントローラーは、モデル レイヤーと現在のビューの状態を変更する責任があります。他には何もありません。
  • 承認は、アクションが実行される場所に属します。厳密な MVC パターンに従っている場合、これはモデルである可能性が高く、コントローラーはモデル アクションの使用を承認する責任を負いません。
  • Cookie は、他のデータストアと同様に扱う必要があります。つまり、コントローラーによって直接ではなく、モデル内で抽象化して使用します。
  • 認証と承認は別々の問題ですが、通常はデータストア (Cookie など) の値に対するチェックが含まれるため、どちらもモデル レイヤーで処理されます。
4

3 に答える 3

9

モデル上のコントローラーに Authorization を配置するために欠落している特定の理由はありますか?

まあ、私が想像できる最も一般的な理由は怠惰です。道徳的にという意味ではありません。モデル層へのアクセスを差別化するよりも、具体的な要求に近い層にいくつかの承認の概念を投げ込む方がはるかに簡単です。モデルの承認を得ることは、はるかに高度な設計です。

答えにさらに実用的なアドバイスを追加するには、承認を導入したい場所と目的をプログラムごとに分析する必要があると思います。そのためのニーズは (非常に) 異なる場合があります。

次のステップでのみ、これらのニーズを満たすために承認と認証を導入するのに最も有益な設計を検討する必要があります。

于 2013-10-18T19:22:25.453 に答える
1

プロセス全体としての承認は、コントローラー層とモデル層の両方に関与する必要があります。

ただし、すべてのログ (SQL クエリなど) は必ずモデル内で発生する必要があります。コントローラーは、ビュー (表現) とモデルの間の一種の中間層です。ただし、コントローラーはセッションと Cookie の処理を​​担当するため、このスキームからコントローラーを捨てることはできません。これら 2 つのものがないと、認証/承認ロジックはすべて役に立たなくなります。これは、本質的にステートレスであるためです。セッションと Cookie はそれに状態をもたらします。さらに、あなたが正しく述べたように、コントローラーはリダイレクトを担当します。

于 2013-10-18T19:19:26.837 に答える