试图找到关于活动记录关联是否应该在 attr_accessible 属性列表中的明确答案。
我见过
class Foo
attr_accessible :name
attr_accessible :bars
belongs_to :bar
end
也见过
attr_accessible :bars_id
想知道能够做到的正确方法 Foo.new(name: 'name' bar: barvar)
试图找到关于活动记录关联是否应该在 attr_accessible 属性列表中的明确答案。
我见过
class Foo
attr_accessible :name
attr_accessible :bars
belongs_to :bar
end
也见过
attr_accessible :bars_id
想知道能够做到的正确方法 Foo.new(name: 'name' bar: barvar)
通常,明确的答案是:“这取决于™”
只有您要批量分配的属性才能访问。
因此,如果您想或需要这样做……</p>
Foo.new(name: 'name', bar: barvar)
......那么你只需要使可bar
访问性。
最后assign_attributes
调用它send("#{attribute_name}=", attribute_value)
在检查属性的可访问性后执行一个简单的操作。
一些编码风格方面:
param
处理哈希时通常会发生批量分配。至少这就是安全问题潜伏的地方。那里你很少有一个Bar
对象,但更常见的是一个bar_id
.
但是,如果您使用模型实例,大多数人更喜欢使用关联方法(如@Andrew Nesbitt 所写),因为这通常具有一些优势(自动保存、自动更新关联对应项、更简洁的代码……)
所以有理由有一个或另一个或两者兼而有之。
我的个人意见:不应该在这个话题上浪费太多时间,因为 Rails 4.0 将有一个更好的参数清理解决方案。(如果你也想在 Rails 3 中看到strong_parameters的话)
您可以避免需要通过使用关联构建器来访问 bar_id:
# singular (has_one)
foo = bar.build_foo(name: 'name')
# plural (has_many)
foo = bar.foos.build(name: 'name')
唯一需要使关联可访问的情况是使用accepts_nested_attributes。
虽然您可以避免在您的示例中使bars_id
(不应该bar_id
吗?)可访问,但问题是您的应用程序的某些部分是否仍需要访问它。使用 active_admin,我必须使whatever_id
可访问的东西与关系一起工作。