Laravel アプリケーションのビジネス ロジックのコード構造、主に行レベルのパーミッションについて、他の意見をお聞きしたいと思います。
ご存じない方のために説明すると、Laravel は Rails によく似た PHP 用の MVC フレームワークです。
理解を深めるために、各ユーザーが自分のアルバムと写真を持っているマルチテナント アプリケーションを想定してみましょう。
- これで、各ユーザーは他のユーザーを自分のアルバムに (写真をアップロードして) 共同作業するように招待できます。
- 写真をアップロードしたアルバムの所有者と共同編集者の両方が、その写真に関する情報を削除または更新できる場合があります。
- 所有者のみがアルバムを編集し、新しい共同編集者を招待できます。
- 共同編集者は、必要に応じて自分自身をアルバムから削除できます。
Pinterest は似たような例の良い例ですが、私たちのアプリケーションはおそらく 3 倍から 4 倍複雑です。問題は、そのようなロジックをどこで処理する必要があるかです。
Laravel は、リポジトリ、エンティティ、およびサービスを使用するアプローチを提案していますが、おそらく良い例が不足しているため、完全には理解できません。したがって、これらの期限を守るための最初の選択肢は、すべてをコントローラーに任せることでした (うーん!)。さて、リファクタリングを掘り下げると、コードのスパゲッティ化を解除する方法はたくさんあります。
- 行レベルで ACL を実装している人々を見てきました (ちょっとばかげてやり過ぎに見えます)
- モデルをデータ コンテナーだけでなく、動作認識オブジェクトに変換
$album->add_photo($photo)して、その関数でパーミッションをチェックすることも可能です。 - モデルの save メソッドをオーバーライドして、そこでそれらのチェックを行うことも可能です。
- または、Laravel が提案した個別の関心層を持つ道に従ってください
次のようなメソッドを使用すると$album->can_be_edited_by($user)、許可されていないルートでの 404 エラーの表示、ビューのリンクの非表示、およびモデルを保存する前の検証が簡素化される可能性があると思います
.NET を使用していないリポジトリ、エンティティ、およびサービスの単純だが理解しやすい例を知っている人はいますか? ありがとう！
編集:各ユーザーには何千ものリソースが関連付けられている可能性がありますが、関連付けの種類ごとに 1 つのロールしかないため、完全な ACL システムは過度のオーバーヘッドを引き起こすと思います。たとえば、写真には がありuploader_id、アルバムには がありowner_idます。