在CanCan Ability类中，哪种域逻辑不合适？

Question

为相当话语的问题道歉，但我想不出一个更好的方式来表达它。我的Rails应用程序中有一个Ability类，它有一些相当复杂的逻辑，我担心我会让CanCan承担太多的责任。这让我想知道当域逻辑应该或不应该进入Ability类时，什么是合理的经验法则。

一个例子：想象一个简化的社交网络，用户可以互相交流。鉴于用户Alice和Bob，如果满足以下条件，Alice可能会与Bob交朋友：

1. Alice没有被停职。
2. Bob向Alice发送了一个朋友请求。
3. Alice和Bob不是朋友。

1似乎非常适合CanCan。如果用户被暂停，他们就不能与人交朋友。你甚至可以通过给用户一个“暂停”角色来指定它。

2似乎非常合适 - 一个用户向另一个用户授予权限。然而，这不是一个非常重要的领域逻辑，可以成为一个能力类吗？能力是否应该在用户模型上调用can_befriend?方法来确定这个？

3对我来说似乎有问题。阻止人们与他们已经是朋友的人交朋友似乎不是一个权限问题，而是一个界面逻辑问题。我们想隐藏“Befriend”按钮不是因为Alice不允许与Bob交朋友，而是因为它不会做任何事情。所以，如果爱丽丝＆amp; Bob已经是朋友，如果要求Alice can?(:befriend, bob)返回true或false？如果这个逻辑确实属于Ability类，不属于属于那个？

Answer 1

我不会将任何内容放在能力上（甚至是＃1）。这种逻辑属于User#befriend(user)（或者你称之为的任何东西）。我使用异能来定义实际权限：用户不应该将照片发布到他们不拥有的专辑等。