【问题标题】:where's the appropriate place to handle writing the current_user.id to an object处理将 current_user.id 写入对象的适当位置在哪里
【发布时间】:2012-02-23 07:34:50
【问题描述】:

我没有使用 Devise,但已经实现了一个简单的身份验证方案(基本上在这里概述了 http://railscasts.com/episodes/250-authentication-from-scratch),相关部分在这里:

application_controller.rb

helper_method :current_user

private
def current_user
  @current_user ||= User.find(session[:user_id]) if session[:user_id]
end

我有一个用户必须有权添加的资产列表。我正在使用回形针。一个用户可以拥有_many 和一个资产属于一个用户(尽管这本质上与它的分配位置无关,因为我的资产模型对于不同的资产类型是多态的)。

我应该在哪里将 current_user id 分配给资产?我会在模型中思考;也许我应该使用 session[:user_id] 做一个 default_values 但这似乎有点难看。

此外,这些是nested_attributes 和这些嵌套的模型,目前对用户一无所知。因此,current_user 的信息来源实际上并不是当前关联的一部分。

谢谢

编辑 1 我应该根据 session[:user_id] 值创建一个 User 的实例还是直接将其推入?

【问题讨论】:

  • 前段时间提出了类似的问题:stackoverflow.com/questions/2513383/…
  • 感谢发布 - 我已经看到了。我实际上并不完全同意当前用户不应该出现在模型中的想法。当价值是逻辑的一部分时,似乎是一种铁路主义。如果逻辑类型在整个应用程序中的实现不一致(有时在控制器中,有时在模型中),我会更加担心,而不是在 100% 的情况下将其放入模型中。特别是在控制器默认不需要触摸模型的情况下。基于在 Rails 中经常发生这种情况的事实,这显然是一个设计目标。

标签: ruby-on-rails activerecord


【解决方案1】:

如果我正确理解了您的问题,为什么不在哪个控制器首先发现资产属于用户时将用户分配给资产?控制器负责将 Web 请求(包括会话/当前用户)转换为适用于模型的内容。

【讨论】:

  • hmm...所以现在,我可以在没有用户的情况下保存资产,在这种情况下,用户并不是真正需要的。在控制器中执行此操作的一个问题是这些资产基本上不会在控制器中触及,因此在控制器中引入它似乎有点笨拙且容易出错。
  • 这家伙是对的;控制器是执行此操作的正确位置。控制器是模型与应用程序状态绑定在一起的地方,而 current_user 绝对是应用程序状态的一部分。
  • 正确 - 问题在于有嵌套属性,您的表单数据基本上绕过了控制器。应该在哪里处理nested_attribute 值,例如user_id。不争论 - 这就是我想要弄清楚的要点。
  • 在我看来,控制器并没有真正被绕过。虽然嵌套表单参数采用模型可以理解的格式很方便,但控制器的工作仍然是在将这些值应用到模型之前处理这些值(如果需要)。所以我会让控制器将 user_id 添加到嵌套参数中,因为用户将其作为会话的一部分隐式提交。
猜你喜欢
  • 1970-01-01
  • 2019-11-09
  • 2021-12-11
  • 2013-08-17
  • 1970-01-01
  • 1970-01-01
  • 2022-01-17
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多