2011-03-18 67 views
1

我来自Asp.Net MVC世界,我很困惑如何从模型的角度来看待Rails 3窗体。 在Asp.Net MVC中,绑定到模板中的业务模型表单是一种不好的做法。正确的做法是为每个表单创建一个类,创建仅在表单中需要的属性并为其添加验证属性。然后在代码中检查ModelState.IsValid并将值从表单模型分配给业务模型。这导致了概念的分离,并且还防止了属性劫持(当黑客可能将额外的值与适当的值一起发布并以他残酷的方式更改业务模型属性时)。Rails 3窗体和模型

从所有的教程和书我读过没有这个概念的Rails世界的制衡 - 你把验证你的商业模式和你的模型绑定到模板的形式。

这是Rails 3中的正确方法,我应该遵循它吗?或者我应该遵循Asp .Net MVC方法,并创建一个单独的模型,并且仅针对表单进行验证?

回答

0

在轨,模型更新通常通过mass-assignment发生。例如,一种形式的帖子一吨属性的更新动作,你的更新动作要求:

Model.update_attributes(params[:model]) 

,并在通过散列所有值更新模型。然后问题是如果黑客增加了什么,

params[:model][:users_attributes][:email] = '[email protected]'` 

并更新模型的关联用户的电子邮件地址?

在Asp.Net MVC中,好像你只是不允许在表单模板中使用它,并且该值永远不会到达你的模型,但是在rails中这不是事情的方式(纠正我,如果我是误解Asp.Net MVC)。在Rails中,模型中的所有内容(默认情况下)都可以批量分配,因此您的担心是有保证的。

在我提供的链接中,您可以看到“例如,对于普通的用户帐户,您只希望用户可以编辑登录名和密码,不应该通过批量分配更改状态属性。 “

class User < ActiveRecord::Base 
    attr_accessible :login, :password 
end 

这意味着任何其他属性必须手动设置和保存的对象,从而防止同类型属性劫持的那Asp.Net的形式的模板防止。在Rails中,什么应该是大规模分配应该在你的attr_accessible然后ActiveRecord的是看门人。不管你如何形式的书面或什么黑客确实他们的HTML,这些属性只能通过明确你的代码不会被Rails的幕后的东西更新。