2

我开始通过railstutorial.org 上的教程学习该框架。我的控制器还不是很可怕，但我可以看到，单一职责主体 (SRP)并没有在整个教程中应用，因为它超出了教程的范围。

我这里有这个相对简单的控制器。我已经可以看到不同的问题（例如身份验证和授权）泄漏到这个控制器中，它包含太多的操作。这会为一个控制器分配太多操作。我偶然发现了专注于 Rails 的控制器，它解决了其中一个问题，看起来很有趣。

这是一个常见的解决方案吗？或者有更好的解决方案吗？

在 .net 世界中，我们倾向于使用面向方面编程 (AOP)来实现更清晰的关注点分离 (SoC)。然而，最近有几个人写了一个新的前端控制器框架，叫做Fubu Behaviors。它很好地捕捉到了请求管道的概念。对我来说越来越有意义的事情。

为了处理请求，我们倾向于在执行操作之前（有时是之后）执行几个步骤。在某些情况下，有条件地结束请求。使用诸如行为、管道或俄罗斯娃娃模式之类的东西似乎很自然。因此，链条中的每个环节都负责继续或停止。继承似乎不是最好的解决方案。

在rails中有类似的东西吗？在rails中有意义吗？

推荐读物同样受欢迎！

4

3 回答 3

2

我同意你的观点，拥有这些授权功能就像is_admin并且correct_user有点代码味道。我会删除它们并使用我经常使用的名为CanCan的宝石更好地处理它。

它允许您将所有授权规则从您的控制器中移出到一个清单（即能力模型）中，只需要您的控制器通过authorize_resource调用您的控制器来启动授权检查。然后你可以在你的处理简单的重定向ApplicationController：

class ApplicationController < ActionController::Base
  rescue_from CanCan::AccessDenied do |exception|
    if current_user
      redirect_to signin_url, :alert => exception.message
    else
      redirect_to root_path, :alert => exception.message
    end
  end
end

除此之外，我会将所有@user = User.find(params[:id])调用移到 before_filter 中，并清理您的缩进和动作顺序（应该是index, new, create, show, edit, update, destroy），我认为您的控制器会很好而且很瘦。

于 2012-10-03T08:16:52.477 回答
1

老实说，我无法确定授权/身份验证应该是模型还是控制器的工作，人们会对此给出各种答案。这就像一个灰色地带。

所以我更喜欢那里的 Rails 约定，因为这些年来它们被证明是值得信赖的。您的控制器对我来说似乎很好，我不会称它们为胖子。您当然可以将这些私有方法移动到帮助程序中。

于 2012-10-02T21:09:06.357 回答
0

对于任何类型的授权逻辑，我实际上会将其从控制器层中删除，并将其移至“策略”层。

使用这个 gem：https ://github.com/NullVoxPopuli/skinny_controllers 它给你两个额外的层

  • 操作
    • 业务逻辑的去向
  • 政策
    • 授权去哪里

自述文件中的一个示例：

module EventOperations
  class Read < SkinnyControllers::Operation::Base
    def run
      # the business logic here is to only check if we will allow this model
      # to be returned
      model if allowed?
    end
  end
end



class EventPolicy < SkinnyControllers::Policy::Base
  # allowed? from the operation delegates to this method
  # here, you could do whatever logic you need to check if the operation
  # is allowed
  def read?(o = object)
    o.is_accessible_to?(user)
  end
end
于 2016-02-25T21:06:52.883 回答