在rails中，这是创建模型，控制器和视图的最佳实践吗？我知道有三种方式。Rails在生成控制器，模型和视图方面的良好实践
1）脚手架“一切”。
2）通过终端生成每个控制器和模型。
3）手动创建所有文件。 （在做这件事时需要小心，我必须记住关于控制器的多元化和在模型中使用单数）
目前，我遵循第三种方法，尽管它涉及一些风险。我只想知道要遵循的最佳做法是什么。如果还有其他方法，我会很高兴知道。谢谢你的时间。
P.S：我是RoR的初学者。
我认为脚手架是相当糟糕的，因为它会产生很多你可能不想要的东西，我只用它来解决问题。
在实际项目中，我的公司规则书说我必须使用测试驱动开发（我喜欢）。这意味着在默认的方法中（有时我无法遵循），我从一个集成测试开始，并从中继续。 （我建立了一个路线，然后是一个控制器方法，然后是一个视图然后是一个模型...）
我相信脚手架是最好的方法，因为它可以自动完成手动创建的整个过程。您将通过rails g scaffold myscaffold获得您的模型，控制器，视图和迁移，这就是为什么我们在rails上将ruby称为敏捷web开发解决方案。因此，支持开发人员快速启动软件或更改功能的工具可以帮助您快速变得灵活。
另一件事是，如果您可以快速引导一个项目，您可能会对优先级的重新排序做出反应更加灵活。这将有助于您的发展计划的核心发展 更清晰和更好的方式。
没有完美的解决方案。如果你手工编码，你真的使用惯用导轨吗？ 对于“中级”程序员 - 既不希望手工编写所有代码，也不能依赖简单的脚手架。你必须理解生成的代码，但是从头开始为大师们留下60 wpm的完美编码！
我推荐三个语
A.得到一个很好的开始。 Boilerplating是在Javascript和Node项目中完成它的主要方式，您可以选择你想要的模块（设计auth，simple_form for ajaxy表单，twitter-bootstrap等），并且开始使用一个相当负载的站点，而不是用零敲碎打的方式。这并不重要 - 只是为了制作“PRO”网站。我仍然在寻找良好的RoR锅炉板，railsapps（作曲家是姐妹网站）和railsbricks，以及良好的旧Rails模板，Rails Engines应该允许你这样做。可悲的是，没有足够的关于如何完成的报道，因为它需要“专家”来提供经过测试的配置，这些配置包含了最佳实践。
B.模型优先方法。从一开始就有一个体面的模型。而不是逐个添加字段，请坐下来尝试为您的网站获取3-4个核心表格，并且他们的关系已经解决。 “敏捷”的人可能会反对极简主义的做法，但如果你有经验，为什么不“设计一点点”。当然，你希望在编码之前避免10个表格或ER图的另一个极端！如果您有体面的模型/用户设计，您可以提前为您的MVP（最小可行产品）预测网站和固有模型的外观。这当然表明你对你想要的应用看起来像有2-4个星期的远见:)
C.测试/迁移更少的脚手架。混合方法更适用于首先进行模型生成和单独数据迁移，然后在没有测试或迁移选项的情况下搭建脚架。你可以看到Rails 4 for Beginners第5章为例子。好处是 - 您不会覆盖手工制作的模型代码，并且让脚手架照顾RoR魔术为您提供的每个模型的〜5 +文件的肮脏细节。 ＃1.生成模型文章的标题，正文 ＃做耙db：创建，手动添加验证，例如存在，最小长度等模型 ＃你可以在这里做一个脚手架.. ＃现在添加位置和数据库迁移摘录ONLY（没有手动模式的编辑也没有脚手架全部） $导轨产生迁移add_excerpt_and_location_to_articles 摘录：字符串位置：串 ＃现在OVERWRITE脚手架而不是模型.. $轨摹脚手架文章大标题：字符串位置：串摘录：字符串 体：text published_at：datetime --skip-migration
如果你明白了 - 你可以看到SCAFFOLDING被TH治疗了ROW-AWAY随着您演变您的模型。在这个时候，你真的不在乎覆盖控制器的细节和视图。但是，您正在保护您的模型，并手动编辑模型之间的关系，以及详细的验证。
作为一个副作用，模型优先的实用性与这种方法一致。停止脚手架之前，您可以在应用程序中获得5-20个模型。那时候，你的代码模型应该是相当确定的。