Rails：向模型添加方法以根据 current_user 执行检查？

Question

我有一个看起来像这样的模型：

class Comment < ActiveRecord::Base
  ...
  #allow editing comment if it is moderated and the user passed-in
  #is the one that owns the comment
  def can_edit?(user)
    moderated? and user.Type == User and user.id == self.user_id
  end
  ...
end

在视图中调用：

<%= link_to 'Show Comment', @comment if @comment.can_show?(current_user) %>

我需要在许多不同的模型中编写许多这样的方法 - 进行验证检查以查看是否允许 current_user 在模型上做某事。

但感觉很麻烦——尤其是需要检查传入的 user 确实是 User 类型的对象。

做这种事情的干净、最佳实践的方法是什么？我走在正确的轨道上吗？ （即我应该将此类方法添加到模型或其他地方）

注意

我使用范围查询来获取评论和其他模型，但在某些情况下我无法确定查询范围，因此我必须使用 can_xxxx? 方法

我正在使用限定范围的查询来获取评论和其他模型，但在某些情况下 我现在的做法算是“胖模特”吗？

Answer 1

创建一个包含所有授权方法的模块，并将该模块包含到所有需要授权的类中。

将名为 authorization.rb 的文件添加到 app/models 目录。

module Authorization

  def can_edit?(user)
    moderated? and user.is_a?(User) and user.id == self.user_id
  end

  def self.included(base)
    base.send(:extend, ClassMethods)
  end

  module ClassMethods
    # add your class methods here.
  end
end

将名为 authorization.rb 的文件添加到 config/initializers 目录。

%w(
 Comment
 Post
).each do |klass|
  klass.constantize.include(Authorization)
end

现在 Comment 和 Post 模型将拥有所有授权方法。

其他方法是使用当前的named_scope。

class Post
  named_scope :accessible, lambda { |user|
    {
      :conditions => { :user_id => user.id, :moderated => true}
    }
  }
end

Post 控制器操作

class PostsController

  def index
    @posts = Post.acessible(current_user)
    # process data
  end

  def show
    # throws record not found when the record is not accessible.
    @post = Post.acessible(current_user).find(params[:id])
    # process data
  end

end

我喜欢这种方法，因为它使用相同的逻辑来访问对象数组或单个对象。

您可以将named_scope添加到模块中以避免重复定义：

module Authorization
  def self.included(base)
    base.named_scope :accessible, lambda { |user|
      {
        :conditions => { :user_id => user.id, :moderated => true}
      }
    }
  end

  module ClassMethods
    # add your class methods here.
  end
end

确保按照前面的建议将模块包含在所需的类中。

Answer 2

我不认为你所做的事情一定是错误的。不过，我看到了三种简化方法：

1）跟踪 self.user 以及 self.user_id。然后您可以说：

def can_show?(user)
  moderated ? and user == self.user
end

注意，这可能会增加数据库查找时间和/或内存占用的开销。

2）使用#is_a？为了检查祖先而不仅仅是类平等：

def can_show?(user)
  moderated ? and user.is_a?( User ) and user.id == self.user_id
end

3）如果传入非用户是错误的，您可能想在发生这种情况时引发错误：

def can_show?(user)
  raise "expected User, not #{ user.class.to_s }" unless user.is_a?(User)
  moderated ? and user.id == self.user_id
end

至于问题2，我还没有听说过术语“胖模型”。是否在任何地方特别提到过？

Answer 3

回复：胖模型和瘦控制器

这是将逻辑推入模型而不是将其放在控制器（或更糟糕的是视图）中的想法。

一个很大的好处是帮助测试；还将更多逻辑放置在模型中而不是控制器中的重点。请记住，控制器与多个模型一起使用并不罕见。

将逻辑放入模型而不是控制器中通常意味着业务规则被纳入模型中——这正是它们所属的位置。

一个可能的缺点是，控制器可用但模型中不可用的任何信息都需要显式传递到模型的方法中或使用模型的实例变量“设置”。

您需要将当前用户传递到模型的示例说明了这个问题。

但总的来说，我和其他许多人发现，胖模特的效果往往比不胖模特的效果更好。