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

Why do Ruby on Rails professionals NOT use Scaffolding?

提问by tmaximini

I read sometimes from people that seem to be working with rails since longer, that one important lesson they learnt would be "Don't use scaffolding". Also on irc I read commonly hints from this direction. My question is why, what is the bad thing about it? And is nifty_scaffoldingbad as well?

我有时会从那些似乎更长时间使用 Rails 的人那里读到，他们学到的一个重要教训是“不要使用脚手架”。同样在 irc 上，我通常会从这个方向阅读提示。我的问题是为什么，它有什么不好的地方？并且是nifty_scaffolding坏呢？

My guess would be it is bad because it generates by default an xml version of your controller action, which would expose the field names of our application to anybody and make it more vulnerable for attacks, so maybe it's this?

我的猜测是它很糟糕，因为它默认生成控制器操作的 xml 版本，这会将我们应用程序的字段名称暴露给任何人并使其更容易受到攻击，所以也许就是这样？

What are your reasons to not do scaffolding?

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

回答by tybro0103

I'm experienced with rails and I rarely use scaffolding simply because my end goal is far from simple CRUD actions. However, there's no strict rule to not use scaffolding. Some coders frown on it because it is actually scaffolding, literally. It's not a finished product. Scaffolding supports you as you build the actual product.Search google images for "scaffolding" and you should get the idea.

我对 Rails 很有经验，我很少使用脚手架，因为我的最终目标远不是简单的 CRUD 操作。但是，没有严格的规定不使用脚手架。一些程序员不喜欢它，因为它实际上是脚手架，字面意思。它不是成品。脚手架在您构建实际产品时为您提供支持。在谷歌图片中搜索“脚手架”，你应该明白了。

Keep in mind scaffoldis just one of many built-in generators in Rails. A Rails generator is simply a script that outputs some generic code. Generators are very useful time-savers, and you'll quickly find yourself writing generatorsfor your own custom needs.

请记住，scaffold它只是Rails中众多内置生成器之一。Rails 生成器只是一个输出一些通用代码的脚本。生成器是非常有用的节省时间的工具，您很快就会发现自己正在为自己的自定义需求编写生成器。

回答by Michael K Madison

I believe most professionals avoid scaffolding because they prefer a test driven development approach to writing production code. This means they want to write a failing test first and then write the code that makes the test pass. This is a great way of producing strong code, but it works best at a very granular level. Scaffolding seems to do too much at one time and so it disrupts a tight loop of writing a failing test for a specific features then writing the code that makes that particular feature pass. It may be more important to get into that habit above and beyond the ease of use of scaffolding.

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

That said scaffolding can be pretty powerful in its own right.

也就是说，脚手架本身就非常强大。

回答by Vikram Sharma

It is important to understand the use of rails generate scaffold and be aware of its limitations. Scaffolding helps you to get something running quickly and test an assumption. But in the real world it will not get you too far. Lets say you created a model with scaffolding

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

rails generate scaffold Article title:string body:text

Great! You now have a prototype ready. But now lets say you have to add another field "author".

伟大的！您现在已经准备好了原型。但是现在假设您必须添加另一个字段“作者”。

rails generate migration add_to_article_author author:string
rake db:migrate

now the table articles has a new column but the files in /app/views/articles are in the same old state i.e. the form will not have author field etc. If you run scaffold again

现在表文章有一个新列，但 /app/views/articles 中的文件处于相同的旧状态，即表单将没有作者字段等。如果您再次运行脚手架

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

This time you have added --skip-migrate because that has been done before and Rails will really complain if you were to migrate the same table again. Now scaffold will prompt you to overwrite the file it created the first time. Overwriting will also destroy any changes you made to your controller /app/controllers/article_controller.rb or views files like /app/views/article/show.html.erb or index.html.erb

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

Since any worthwhile Rails app has custom code (and not boilerplate code created by scaffold) a Rails programmer should use scaffold only to test an idea. Use scaffold to give your client something to play with. But in real world boilerplate scaffold code is not used.

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

回答by coreyward

Scaffolding isn't really meant for production use. It's meant to get an application bootstrapped quickly and then it can be modified or done away with.

脚手架并不真正用于生产用途。它的目的是让应用程序快速启动，然后可以修改或取消它。

The Rails 3 scaffolding is actually pretty decent, but it still lacks some things like a way to handle nested resources and it doesn't use the simpler respond_with(over respond_to, which encourages verbosity where it isn't needed or welcome).

Rails 3 脚手架实际上相当不错，但它仍然缺乏一些东西，例如处理嵌套资源的方法，并且它不使用更简单的respond_with（over respond_to，这鼓励在不需要或不受欢迎的地方冗长）。

It's unlikely that the default scaffold forms will work un-modified, either —?you probably have relationships between your models that translate to a column in the database like user_id. When creating a scaffold of a model with a relationship, this column shows up as a text field in the form when clearly it should be inferred from the URL or selected via another, more user-friendly, interface.

默认的脚手架表单不太可能在未修改的情况下工作 -？您的模型之间可能有关系转换为数据库中的列，例如user_id. 在创建具有关系的模型的脚手架时，此列在表单中显示为文本字段，显然应该从 URL 推断或通过另一个更用户友好的界面选择。

There are a lot of small details like this that make scaffolding a really unlikely candidate for production-ready-out-of-the-box code. You can certainly build an application by generating the scaffold and then filling in the gaps and cleaning up areas you don't need, though, and I suspect most Rails developers do this to some extent.

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

回答by stephenmurdoch

I don't use scaffolding for two reasons:

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

• Rails scaffolding puts everything in a html tables - I don't like that
• I prefer to use rails_admingem for my admin pages so there is no need for 90% of the scaffold code

• Rails 脚手架将所有内容都放在 html 表中 - 我不喜欢那样
• 我更喜欢将rails_admingem 用于我的管理页面，因此不需要 90% 的脚手架代码

Your xml concerns are not the reason why people advise against using scaffolding. I don't bother with XML versions of my pages as it doubles the number of routes your app must generate, which in turn increases the overheads a little...

您对 xml 的担忧并不是人们建议不要使用脚手架的原因。我不关心我的页面的 XML 版本，因为它使您的应用程序必须生成的路由数量加倍，这反过来又增加了一点开销......

回答by Mike Campbell

People thus far have said that experienced rails programmers don't use scaffolding, and for good reasons mainly. I advocate that beginners don't use scaffolding either.

迄今为止，人们都说有经验的 Rails 程序员不使用脚手架，这主要是有充分的理由。我主张初学者也不要使用脚手架。

You may have been plodding along happily for some time with scaffolding, and then you realise that you forgot to include the publishedboolean field for your Post model, so you generate a migration to add the attribute to the table (you've managed to work that out). You then also have to work out how to add that to the form that scaffold produced. Thenfor the life of you you can't work out why it's not updating when you submit your form, and after much strife and wasted time you figure out you haven't permitted mass assignment on that attribute like scaffold did for you on the others. Turns out you don't really know anything about how Rails works.

您可能已经愉快地使用脚手架进行了一段时间的工作，然后您意识到您忘记published为 Post 模型包含布尔字段，因此您生成了一个迁移以将该属性添加到表中（您已经成功地做到了这一点）出去）。然后，您还必须弄清楚如何将其添加到脚手架生成的表单中。然后在您的一生中，您无法弄清楚为什么在您提交表单时它没有更新，经过多次冲突和浪费时间，您发现您没有允许在该属性上进行批量分配，就像 scaffold 在其他属性上为您所做的那样. 事实证明，您对 Rails 的工作原理一无所知。

If you're learning Rails, you'd understand much more about MVC if you built the M the V and C yourself.

如果您正在学习 Rails，如果您自己构建了 M、V 和 C，您将对 MVC 了解更多。

回答by user12425838

I am professional Rails developer and I use scaffolding all the time, in fact I can make a pretty decent argument that reproducibility and predictability of scaffolding can make the whole process of learning rails and using rails easier.

我是专业的 Rails 开发人员，我一直在使用脚手架，事实上我可以提出一个相当不错的论点，即脚手架的可重复性和可预测性可以使学习 Rails 和使用 Rails 的整个过程变得更容易。

The approach we use is to always start with scaffolding and then as time goes along and we see patterns customise the scaffolding for the project.

我们使用的方法总是从脚手架开始，然后随着时间的推移，我们看到模式为项目定制了脚手架。

This approach means that we have an approach when we learn we bake knowledge back into the project and when we find issues we fix them in one place and all subsequent uses of the scaffold have that learning instead of constantly having to explain, justify and educate different developers at different skill levels.

这种方法意味着我们有一种方法，当我们学习时我们将知识重新融入到项目中，当我们发现问题时我们在一个地方解决它们，并且脚手架的所有后续使用都有这种学习，而不是不断地解释、证明和教育不同的不同技能水平的开发人员。

In my experience the biggest issue with rails is its greatest strength! It is the malleability of a rails project is what causes it to be hard to maintain. Lots of ways to achieve the same-thing which is not wrong but does make it hard to pick up from somebody else who has started the project.

根据我的经验，rails 最大的问题是它最大的优势！Rails 项目的延展性是导致它难以维护的原因。有很多方法可以实现相同的目标，这并没有错，但确实很难从启动该项目的其他人那里学到东西。

Is our approach fUN , debatable! Is it reproducible, effective, efficient while leaning on rails instead of fighting it , 100% yes!

我们的方法是否有趣，值得商榷！依靠铁轨而不是对抗它，它是否可重复、有效、高效，100% 是的！

回答by Matthias

I think scaffolding is very good to check out the new stuff of new rails versions (for example now in rails 4 the params permit stuff in a controller). You can use it for fast prototyping. Often it is simple not necessary to generate a full scaffold..

我认为脚手架非常适合检查新 Rails 版本的新内容（例如，现在在 rails 4 中，params 允许控制器中的内容）。您可以使用它进行快速原型设计。通常很简单，没有必要生成一个完整的脚手架。