ruby-on-rails - Scaffold 在 Rails 中是一种好的还是正常的做法？

Question

我是一名 PHP 开发人员，我使用过的任何框架都推荐使用脚手架进行测试。

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

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

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

score 2 · Accepted Answer

脚手架是 Rails 应用程序的一种标准结构。由于 ruby 是一种极其灵活的语言，我认为 Rails 实现这个特性只是为了引导新手让事情以相对统一的方式工作。

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

PS：对于一些场景，比如搭建admin平台，scaffold确实是一个很好用的工具。因为标准表，CRUD 操作只是管理员的日常工作。脚手架可以节省这类东西的时间。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

如果你确实创建了一个脚手架，你应该仔细检查它并删除所有你不想在生产环境中暴露的部分。对于一个简单的博客，您可能只需要 index 和 show 功能，并删除创建、更新和销毁条目的能力（或者至少使用一些身份验证解决方案保护它们，以便只有您可以这样做）。

我会说脚手架生成的代码可以在生产中使用，更重要的是您需要注意您为公共用户提供的特权。

如果不出意外，脚手架非常适合了解数据库驱动的应用程序是如何工作的。

根据具体情况，我会在生成模型时为模型搭建支架，然后删除我不需要的东西并根据我的要求对其进行调整（包括添加测试）。我通常发现这比从头开始编写所有代码要快（尤其是当它同时生成数据库迁移文件、测试文件并将模型资源添加到路由文件时）。