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

时间:2013-09-25 14:51:40

标签: ruby-on-rails ruby-on-rails-3 ruby-on-rails-4 scaffolding

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

所以,我的问题是:在Rails中也是如此?

建议在生产中使用脚手架(仅用于CRUD,例如:博客)

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

3 个答案:

答案 0 :(得分:2)

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

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

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

答案 1 :(得分:1)

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

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

答案 2 :(得分:1)

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

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

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

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

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