为什么Ruby on Rails专业人士不使用Scaffolding？

Question

我有时会看到那些似乎更长时间使用rails的人,他们学到的一个重要教训是"不要使用脚手架".同样在irc上我从这个方向读了一些提示.我的问题是为什么,它有什么坏处？并且nifty_scaffolding也不好吗？

我的猜测是它是坏的,因为它在默认情况下产生的控制器动作的XML版本,这会暴露我们的应用程序的字段名称任何人,使之成为攻击更加脆弱,所以也许这是这个？

你不做脚手架的原因是什么？

Answer 1

我对rails很有经验,我很少使用脚手架,因为我的最终目标远非简单的CRUD操作.但是,没有严格的规则不使用脚手架.一些编码员皱眉头,因为它实际上是脚手架,字面意思.它不是成品.在构建实际产品时,脚手架支持您.搜索谷歌图片"脚手架",你应该明白这个想法.

请记住scaffold,只是Rails中许多内置生成器之一.Rails生成器只是一个输出一些通用代码的脚本.生成器是非常有用的节省时间的,你很快就会发现自己编写生成器来满足自己的自定义需求.

Answer 2

我相信大多数专业人士都避免使用脚手架,因为他们更喜欢使用测试驱动的开发方法编写生产代 这意味着他们希望首先编写失败的测试,然后编写使测试通过的代码.这是生成强代码的好方法,但它在非常精细的级别上工作得最好.脚手架似乎一次做得太多,因此它破坏了为特定功能编写失败测试的紧密循环,然后编写使特定功能通过的代码.除了易于使用脚手架之外,养成这种习惯可能更为重要.

据说脚手架本身就非常强大.

Answer 3

了解使用rails生成脚手架并了解其局限性非常重要.脚手架可以帮助您快速运行并测试假设.但在现实世界中,它不会让你走得太远.假设您创建了一个带脚手架的模型

rails generate scaffold Article title:string body:text

大!你现在有一个原型准备好了.但现在让我们说你必须添加另一个字段"作者".

rails generate migration add_to_article_author author:string
rake db:migrate

现在表格文章有一个新列,但/ app/views/articles中的文件处于相同的旧状态,即表单不会有作者字段等.如果再次运行scaffold

rails generate scaffold Article title:string author:string body:text --skip-migration

这次你添加了--skip-migrate,因为之前已经完成了,如果你再次迁移同一个表,Rails会真的抱怨.现在,scaffold会提示您覆盖它第一次创建的文件.覆盖还会破坏您对控制器/app/controllers/article_controller.rb所做的任何更改或查看/app/views/article/show.html.erb或index.html.erb等文件

由于任何有价值的Rails应用程序都有自定义代码(而不是脚手架创建的样板代码),Rails程序员应该只使用scaffold来测试一个想法.使用脚手架为您的客户提供一些可玩的东西.但在现实世界中,样板脚手架代码未被使用.

Answer 4

脚手架不是真正意义上的生产用途.它的目的是让应用程序快速启动,然后可以修改或完成.

Rails 3脚手架实际上相当不错,但它仍然缺少一些处理嵌套资源的方法,并且它不使用更简单的respond_with(over respond_to,鼓励在不需要或不欢迎的情况下的冗长).

默认的脚手架形式也不太可能在未经修改的情况下工作 - 您可能在模型之间存在转换为数据库中的列的关系user_id.在创建具有关系的模型的支架时,此列显示为表单中的文本字段,清楚地表明它应该从URL推断或通过另一个更加用户友好的界面选择.

有很多这样的小细节使得脚手架成为生产就绪的开箱即用代码的一个非常不可能的候选者.你当然可以通过生成脚手架来构建一个应用程序,然后填补空白并清理你不需要的区域,我怀疑大多数Rails开发人员在某种程度上这样做.