かなり議論の余地のある質問で申し訳ありませんが、より良い言い方が思いつきません。私の Rails アプリにはかなり複雑なロジックを持つ Ability クラスがあり、CanCan に責任を負わせすぎているのではないかと懸念しています。これにより、ドメインロジックをAbilityクラスに入れる必要がある場合と入れるべきでない場合の合理的な経験則は何だろうと思いました。
例: ユーザーが互いに友達になれる単純化されたソーシャル ネットワークを想像してみてください。ユーザーが Alice と Bob の場合、次の条件が満たされている場合、Alice は Bob と友達になることができます。
- アリスは停止されていません。
- Bob は Alice に友達リクエストを送信しました。
- Alice と Bob はまだ友達ではありません。
1 は明らかに CanCan に適しているようです。ユーザーが停止されている場合、ユーザーは他の人と友達になることはできません。ユーザーに「一時停止」ロールを与えることで、これを指定することもできます。
2 は非常に適しているようです。あるユーザーが別のユーザーに権限を付与します。しかし、これはかなり重要なドメイン ロジックであり、Ability クラスに分割されているのではないでしょうか? can_befriend?
これを判断するために、アビリティはユーザー モデルのメソッドを呼び出す必要がありますか?
3は私には問題があるようです。すでに友達になっている人と友達になるのを止めることは、許可の問題ではなく、インターフェースロジックの問題のようです。「友達になる」ボタンを非表示にしたいのは、アリスがボブと友達になることを許可されていないからではなく、何もしないからです。Alice と Bob が既に友達である場合、Alice の呼び出しはcan?(:befriend, bob)
true または false を返す必要がありますか? そして、このロジックが能力クラスに属している場合、そこに属していないものは何ですか?