#9 楼 @Rei 哈哈对一般后端开发人员来说的确不了解 JS。但只要对了解 JS 语言的话，其实也不算太糟。如果你尝试一下 Node.js 的性能，绝对会对它刮目相看的。我当时简单的测试了一下，基本上 Nginx 的上万并发对 Node.js 来说在一个水准。但如果换成 ROR，早就连进程都跑崩了。

补充一下，实际上我觉得 ROR 和 Node.js 没有太大的可比性。ROR 是一个基于 Ruby 的 Framework。而 Node.js 可以算作一个 interpreter。但如果 Node.js 社区搞出个类似 ROR 的 Framework，我估计风暴就要来临了。

通常来说，一个大型项目里并非非得用一种语言。 用 Python/Ruby + C，用 Nginx+Lua，用 PHP+node.js 都是很常见的情况。只要架构设计合理，逻辑分层，会很容易把需要高性能运算的作业请求转发给 Node.js、openrestry、C、Java 等后端。 在数据层也是一样的，Memc、Redis、Mongo 等都是很好的数据缓存工具。

#7 楼 @Rei 赞同。在生产环境，ROR 不会给出详细的错误提示，但会给出 500 Error。定义一下这个页面就行了。

#25 楼 @hhuai #26 楼 @help5305fff 这个主要取决于项目的类型，涉及仓储库存之类的数据库应用会用得比较多，因为这类应用几乎是 CURD 的大集合。

#18 楼 @knwang #20 楼 @ugoa

从 knwang 的经验来看，的确是这样的。 对于初学者，只要了解了 MVC，或者以前接触过类似的东西，我往往会换一种思路进行解释。

先从新建一条 Route 开始（比如我想制作一个叫/testing 的页面），就会给出“找不到控制器”的错误；然后进而告知控制器的文件命名及相关规则，引导其建立一个匹配的 Controller。紧接着系统提示“Template”找不到的错误。再然后理所当然新建一个模板，一个新手写的 Hello world 诞生。水到渠成。

虽然这个例子不涉及数据库，但初学者往往能一下子对整个 ROR 的体系有非常直观的认识，并且会逐步主动尝试去修改模板变量等内容。这个过程远远比解释 Scaffold 生成的各个文件来得自然。

#13 楼 @_samqiu 但有一点要留意：手动创建文件，新手会有一个直观的体验，他会知道，这些文件就是一个功能的关键。他会清清楚楚的知道，这些 demo 都是自己亲手创建的。 一个熟练使用 ROR 的人，虽然也会倾向于使用 scaffold——但这是建立在完全了解 ROR 这一特征的基础之上的。

Scaffold 的确简单，简单是简单了——但这对新手了解 MVC 之间真正的联系有多大帮助吗？

#1 楼 @fredwu 呃。月经了。

#9 楼 @iBachue 误解了。我是指官方的那篇 Guide。

#7 楼 @yzhrain “要说新人不知道如何创建一个 M, 一个 V，感觉这和 scaffold 没关系啊，你不去理解它，如何会知道它是怎么样创建的呢？”

我不认同。一个良好的帮助，应该是教初学者一步一步创建出 M，V，C。这其实并不难，创建三个文件而已。只需要手把手做完这三步，立即会对 ROR 中的 MVC 模型有一个深刻而具象的认知。而不是像现在这样：很多初学者做完了 Demo，却感觉自己被蒙在鼓里，没有一点而兴奋——因为这个 demo 实际上不是他本人“亲手”完成的，而是归功于脚手架。

当一步一步地完成一个简单的 demo 之后，再告诉学习者：其实不必如此麻烦的，ROR 已经为你准备好了一个叫 Scaffold 的工具，它可以帮你创建好上面的文件。实至名归。

#6 楼 @Rei 我认为，指导一步一步创建出 M、V、C，让读者能够对 MVC 有个直观的体验与认知，亲手写出能用的 Hello world，可能会更有成就感。

#2 楼 @huacnlee 我认为这个功能主要应用在于：数据库管理、库存、进存销管理、博客系统等。这种系统以数据库业务逻辑为中心，脚手架很快就能把原型搭建起来。

但更多的应用并非数据库简单的增删改查，而是更多复杂的逻辑。使用脚手架生成出来的简单的模型反而会不合适。

上面的方法都要警惕 Array 里第一个元素为 0 的情况。这是坑。