Rails 3窗體和模型

我來自Asp.Net MVC世界，我很困惑如何從模型的角度來看待Rails 3窗體。在Asp.Net MVC中，綁定到模板中的業務模型表單是一種不好的做法。正確的做法是爲每個表單創建一個類，創建僅在表單中需要的屬性併爲其添加驗證屬性。然後在代碼中檢查ModelState.IsValid並將值從表單模型分配給業務模型。這導致了概念的分離，並且還防止了屬性劫持（當黑客可能將額外的值與適當的值一起發佈並以他殘酷的方式更改業務模型屬性時）。Rails 3窗體和模型

從所有的教程和書我讀過沒有這個概念的Rails世界的制衡 - 你把驗證你的商業模式和你的模型綁定到模板的形式。

這是Rails 3中的正確方法，我應該遵循它嗎？或者我應該遵循Asp .Net MVC方法，並創建一個單獨的模型，並且僅針對表單進行驗證？

來源

2011-03-18 sha1dy

在軌，模型更新通常通過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的幕後的東西更新。

來源

2011-03-18 16:06:36

Rails 3窗體和模型

回答

相關問題