logo标签列表

为什么Ruby on Rails专业人士不使用脚手架？

ruby-on-railsruby-on-rails-3scaffolding
66

有些使用Rails较长时间的人会说他们学到了一条重要课程：“不要使用脚手架”。我在IRC上也经常看到这个方向的提示。我的问题是，为什么？它有什么坏处？而 nifty_scaffolding 又是否糟糕呢？

我猜测它之所以不好，可能是因为它默认生成控制器动作的 XML 版本，这将向任何人公开应用程序的字段名称，并使其更容易受到攻击，所以可能是这个原因？

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

我已经准备好了所有的答案，但是我没有足够的理由来说“不要使用脚手架”，只有一些建议当你决定使用它时。 - alex
9个回答
71

我在Rails方面有经验，但很少使用脚手架，因为我的最终目标远非简单的CRUD操作。然而，并没有严格的规定不能使用脚手架。一些程序员不喜欢它，因为它实际上就像是搭建一座建筑时用的scaffolding（脚手架），它不是最终成品。 脚手架在构建实际产品时能够支持您。在谷歌图片中搜索“脚手架”，您应该就能了解到这个概念。

请记住，scaffold只是Rails中许多内置生成器之一。Rails生成器只是输出一些通用代码的脚本。生成器非常有用，可以节省时间，您很快就会编写自己的生成器来满足自己的特定需求。

12

我相信大多数专业人士避免使用脚手架，因为他们更喜欢测试驱动的开发方式来编写生产代码。这意味着他们想先编写一个失败的测试，然后再编写使该测试通过的代码。这是生成强大代码的好方法，但它在非常粒度化的层面上效果最佳。脚手架似乎一次做得太多，因此会打破编写特定功能的失败测试，然后编写使该特定功能通过的代码的紧密循环。重要的是养成这个习惯，并超越使用脚手架的便利性。

话虽如此，脚手架本身也可以非常强大。

11

了解rails generate scaffold命令的使用并注意其局限性是很重要的。脚手架可以帮助你快速启动一个项目并测试假设，但在真实世界中，它并不能让你走得太远。比如说，你使用脚手架创建了一个模型。

rails generate scaffold Article title:string body:text

太好了！现在你已经准备好了原型。但是现在假设你需要添加另一个字段“作者”。

rails generate migration add_to_article_author author:string
rake db:migrate

现在表格"articles"有了一个新的列，但是在/app/views/articles目录下的文件仍然保持原样，即表单不会有作者字段等。如果您再次运行脚手架命令

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程序员应该仅使用脚手架来测试想法。使用脚手架为客户提供可以操作的东西。但在实际工作中，样板脚手架代码并不会被使用。
我在每个项目中都使用脚手架。它为我设定了所需实现的样板方案。请注意，我使用最少量的样板。添加属性等内容与从头开始相同。如果您不想使用表格，则可以自行格式化样板。这样可以节省大量测试时间，以避免拼写错误、属性、文件名或列。我还有一个额外的脚本，在使用脚手架生成资源后运行，帮助我将其调整到我目前正在使用的位置。 - user1898553
6
脚手架并不是真正用于生产环境的。它的作用是快速启动应用程序，然后可以进行修改或删除。
Rails 3的脚手架实际上相当不错，但仍然缺少一些功能，比如处理嵌套资源的方法以及没有使用更简单的respond_with(而是使用respond_to)，这会在不需要或不受欢迎的地方鼓励冗余代码。
默认的脚手架表单很可能无法直接使用，因为您的模型之间可能存在关系，这些关系会转换成数据库中的列，例如user_id。在创建具有关系的模型的脚手架时，在表单中，该列显示为文本字段，而显然应该从URL中推断出来或通过其他更用户友好的界面进行选择。
有许多类似这样的小细节，使得脚手架成为一个不太可能的候选项，用于生产环境的开箱即用代码。但是，您可以通过生成脚手架并填补空白部分和清理不需要的区域来构建应用程序，我认为大多数Rails开发人员都会在某种程度上这样做。
好的，我认为需要修改脚手架创建的代码是很清楚的，但我更关心脚手架的潜在危险或缺陷。 - tmaximini
在其他框架中，可能存在安全问题。但是Rails的脚手架非常可靠，因此除了依赖于脚手架之外，实际上并没有什么硬伤害。 - coreyward
3

我不使用脚手架有两个原因：

  • Rails脚手架将所有内容放在HTML表格中-我不喜欢那样
  • 我更喜欢使用rails_admin gem来处理我的管理页面，因此90%的脚手架代码是不需要的

你关心的XML问题并不是人们反对使用脚手架的原因。我不会为我的页面创建XML版本，因为这会使你的应用程序生成的路由数量增加一倍，从而稍微增加了开销...

2
PS- 在学习Rails时，建议使用脚手架工具，因为它可以减少你需要了解的内容，并帮助你更快地启动应用程序。一旦你掌握了技巧，自然就不会再使用生成器了。 - stephenmurdoch
1
输出格式在控制器中的一小段代码中处理。Rails原生支持JSON和XML，因此您甚至不需要视图。您的路由对于格式根本不会改变（运行rake routes并查看每个路由末尾的隐式(.:format)）。 - coreyward
是的，我也只使用nifty_scaffolding，因为它似乎更精确，省略了很多不必要的代码，并且在我看来提高了安全性。 - tmaximini
@coreyward，说得好，我忘记了Rails几年前删除了格式化路由 http://ryandaigle.com/articles/2008/11/27/what-s-new-in-edge-rails-no-more-formatted-routes - stephenmurdoch
2
迄今为止，人们普遍认为有经验的Rails程序员不使用脚手架，主要是有好的原因。我主张初学者也不要使用脚手架。
你可能一直在愉快地使用脚手架，然后你意识到你忘记在你的Post模型中包含“published”布尔字段，所以你生成一个迁移来添加属性到表格中（你已经设法解决了这个问题）。然后你还必须想办法将其添加到脚手架生成的表单中。然后你提交表单时它更新不了，你尝试了很多次却无效，最后浪费了很多时间才发现你没有像脚手架那样允许该属性进行大规模任务分配。结果证明你对Rails工作原理一无所知。
如果你正在学习Rails，如果你自己构建MVC，你将更好地理解MVC。
“原来你对Rails的工作原理一无所知” nailed it. - suzumakes
1
这句话有一定的道理，但另一方面，对于那些不了解Rails工作原理的人来说，脚手架可以展示给他们一个非常简单的版本，让他们了解它的工作方式。 - stevec
1
我是专业的Rails开发人员，经常使用脚手架。事实上，我可以提出一个相当合理的论点，即脚手架的可重复性和可预测性可以使学习和使用Rails的整个过程更加容易。
我们采用的方法是始终从脚手架开始，随着时间的推移，根据项目需求定制脚手架。
这种方法意味着当我们学习时，我们将知识应用于项目中；当我们发现问题时，我们在一个地方修复它们，所有后续使用脚手架的地方都有了这种学习，而不必不断解释、证明和教育不同技能水平的开发人员。
在我的经验中，Rails最大的问题就是它的优点！Rails项目的可塑性是导致其难以维护的原因。有很多方法可以实现同样的事情，这并不是错的，但会使得从已经开始项目的其他人那里接手变得困难。
我们的方法是否有趣，值得商榷！它是否可重复、有效、高效，同时借助Rails而不是与之抗争，100%肯定！
1

如果你是Rails的新手，使用scaffolding没什么用，因为你不理解所有不同文件是如何生成的，从学习角度来看，最好先了解Rails的工作原理，再使用scaffolding。

如果你已经有Rails的经验，使用scaffolding也没什么用，因为后端和API通常比简单的CRUD应用程序更复杂。如果我在当前项目中使用scaffolding，我需要删除很多样板文件。

同意。这就是《Rails 教程》书中所教授的内容。 - BugHunterUK
0

我认为脚手架非常适合检查新版本的新内容（例如现在在Rails 4中的控制器参数允许的内容）。您可以将其用于快速原型设计。 通常，不需要生成完整的脚手架就可以实现目标。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接