在Rails中，脚手架是一种好的或正常的做法？

Question

我是一名PHP开发人员，我使用的任何框架，建议仅用于测试。

所以，我的问题是：在Rails中也是如此？

建议在生产中使用脚手架（仅用于CRUD，例如：博客）

因为，事情是不同的：在某些PHP框架中，脚手架视图在每个请求中被处理/创建，但在Rails中（我认为），文件已经创建。

Answer 1

脚手架是Rails app的标准结构。由于ruby是一种致命的灵活语言，我认为Rails实现此功能只是为了引导新来者以相对统一的方式使事情发挥作用。

无论如何，它遵循RESTful模式的最佳实践。虽然我们不会总是使用“rails g scaffold xxx ...”，但程序的主要文件结构就像脚手架一样。

PS：对于某些情况，例如构建管理平台，scaffold确实是一个很好的工具。因为标准表，CRUD操作只是管理员的日常工作。脚手架可以节省很多时间。

Answer 2

大多数开发人员不使用脚手架。

这不是世界上最糟糕的事情，但它会给你一个通用的，开箱即用的设置。我个人认为最好避免在刚开始的时候，因为那时你不会很好地学习基础知识。当你更熟练的时候最好避免，因为它可能不会给你你想要的东西。

Answer 3

您需要注意，如果为模型生成Rails脚手架，它将生成在数据库中创建，读取，更新和删除（CRUD）所需的所有代码。您可能不希望在生产环境中为所有用户提供这种特权（特别是更新和删除），这就是为什么盲目地将脚手架代码上传到生产中是危险的。

如果您确实创建了一个脚手架，您应该检查它并删除您不希望在生产环境中暴露的所有部件。对于一个简单的博客，您可能只需要索引和显示函数，并删除创建，更新和销毁条目的能力（或至少使用某些身份验证解决方案保护它们，以便只有您可以这样做）。

我想说脚手架生成的代码可以很好地用于生产，更需要注意你给公众用户的特权。

如果不出意外，支架非常适合学习数据库驱动的应用程序如何工作。

根据具体情况，我会在生成模型时使用我的模型，然后移除我不需要的东西，并根据我的要求（包括添加测试）进行定制。我通常发现比从头编写所有代码更快（特别是当它生成数据库迁移文件时，测试文件并同时将模型资源添加到路径文件中）。