我对Rails很有经验，我很少使用scaffolding，因为我的最终目标远不是简单的CRUD操作。但是，没有严格的规则禁止使用scaffolding。一些程序员不赞成它，因为它实际上是 scaffolding，字面意思。它不是一个成品。**Scaffolding支持你构建实际的产品。**搜索谷歌图片中的“scaffolding”，你应该明白了。
请记住，scaffold只是Rails中内置的生成器之一。Rails生成器只是一个输出一些通用代码的脚本。生成器非常有用，可以节省时间，您很快就会发现writing generators可以满足您自己的定制需求。

我相信大多数专业人士都避免搭建，因为他们更喜欢测试驱动的开发方法来编写产品代码。这意味着他们想先编写一个失败的测试，然后再编写使测试通过的代码。这是一个产生强大代码的好方法，但它在非常细的级别上工作得最好。支架似乎一次做得太多了，所以它破坏了一个紧密的循环，即为一个特定的特性编写一个失败的测试，然后编写使该特定特性通过的代码。除了脚手架的易用性之外，养成这种习惯可能更重要。
也就是说，脚手架本身就非常强大。

理解rails生成scaffolding的用法并意识到它的局限性是很重要的。Scaffolding帮助你快速运行一些东西并测试一个假设。但在真实的世界中它不会让你走得太远。假设你用scaffolding创建了一个模型

rails generate scaffold Article title:string body:text

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

rails generate migration add_to_article_author author:string
rake db:migrate

现在表articles有一个新列，但/app/views/articles中的文件仍处于相同的旧状态，即表单将没有author字段等。如果再次运行scaffold

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

这一次您添加了--skip-migrate，因为之前已经这样做过了，如果您再次迁移同一个表，Rails会非常不满。现在scaffold会提示您覆盖它第一次创建的文件。覆盖还会破坏您对controller /app/controllers/article_controller.rb或视图文件（如/app/views/article/show.html.erb或index.html.erb）所做的任何更改
因为任何有价值的Rails应用程序都有自定义代码（而不是由scaffold创建的样板代码），Rails程序员应该只使用scaffold来测试一个想法。使用scaffold给予你的客户一些东西来玩。但在真实的世界中，样板代码是不使用的。

搭建并不是真正用于生产，它的目的是让应用程序快速启动，然后可以修改或删除它。
Rails 3搭建实际上相当不错，但它仍然缺乏一些东西，比如处理嵌套资源的方法，并且它没有使用更简单的respond_with（在respond_to之上，在不需要或不受欢迎的地方鼓励冗长）。
默认的scaffold表单也不太可能在未经修改的情况下工作--您的模型之间可能有一些关系，这些关系转换为数据库中的一列，比如user_id。当创建一个具有关系的模型的scaffold时，该列在表单中显示为一个文本字段，而显然它应该从URL中推断出来，或者通过另一个更用户友好的界面来选择。
有很多像这样的小细节使得scaffolding不太可能成为生产就绪的开箱即用代码。当然，您可以通过生成scaffolding来构建应用程序，然后填充空白并清理您不需要的区域，我怀疑大多数Rails开发人员在某种程度上都是这样做的。

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

• Rails搭建将所有内容都放在html表中-我不喜欢这样
• 我更喜欢使用rails_admin gem作为管理页面，因此不需要90%的scaffold代码

你对xml的担忧并不是人们反对使用scaffolding的原因。我不喜欢我的页面的XML版本，因为它会使你的应用必须生成的路由数量加倍，这反过来会增加一点开销。

到目前为止，人们都说有经验的Rails程序员不使用scaffolding，这主要是有充分的理由的。
您可能已经愉快地使用scaffolding沿着了一段时间，然后您意识到忘记为Post模型包含published布尔字段，因此您生成迁移以将属性添加到表中（你已经设法解决了这个问题）。然后你还必须解决如何将它添加到脚手架产生的形式中。* 然后 * 在你的一生中，你可以'我不明白为什么在提交表单时它没有更新，经过一番争论和浪费时间之后，您发现您不允许像scaffold那样对该属性进行批量赋值。
如果你正在学习Rails，如果你自己构建了M、V和C，你会对MVC有更多的了解。

我是专业的Rails开发人员，我一直在使用脚手架，事实上，我可以提出一个相当体面的论点，即脚手架的可重复性和可预测性可以使学习Rails和使用Rails的整个过程更加容易。
我们使用的方法是总是从搭建开始，然后随着时间的沿着，我们看到模式为项目定制搭建。
这种方法意味着，当我们学习时，我们有一种方法，我们把知识带回到项目中，当我们发现问题时，我们在一个地方修复它们，所有后续的支架使用都有这种学习，而不是不断地解释、证明和教育不同技能水平的不同开发人员。
根据我的经验，Rails最大的问题是它最大的优势！Rails项目的可塑性是它难以维护的原因。有很多方法可以实现同样的目标，这并没有错，但确实很难从其他启动该项目的人那里学到东西。
我们的方法是否有趣，值得商榷！它是否可重复，有效，高效，同时依靠轨道而不是对抗它，100%是的！

如果你是Rails新手，那么使用scaffolding几乎没有什么用处，因为你不明白为什么以及如何生成各种文件。从学习的Angular 来看，学习Rails如何工作而不使用scaffolding是有意义的。
如果你对Rails有经验的话，使用scaffolding几乎没有什么用处，因为后端和API通常比简单的CRUD应用程序更复杂。如果我在我目前的项目中使用scaffolding，我必须删除很多样板文件。

我认为搭建是非常好的检查新的Rails版本的新东西（例如现在在rails 4中params允许在一个控制器中的东西）。你可以使用它快速原型。通常它是简单的，没有必要生成一个完整的搭建。