Rails 2.x和约定与“企业”架构

Question

注:这是从2008年春天，因此古老的铁路土地。

(这个标题可能不太好，我想不出更好的标题了)

我即将重新审视一个创业想法，我选择的平台是Rails。我最近还开始重新阅读“企业Rails”(Enterprise)一书，这本书建议您不要遵循Rails的默认约定，而是将层划分为“物理”和“逻辑”组件。这是我唯一的一本书，我还没有看到这种观点的表达方式；其他所有的Rails书籍似乎都只是遵循“约定而不是配置”的口号。简而言之，书中的建议将您的应用程序/文件夹划分为以下几个部分：

• app/models/物理(用于实际的.rb模型文件)
• 应用程序/模型/逻辑(我认为用于web服务API)

对你的控制器和应用程序的其他区域也做同样的事情。这本书还建议不要使用数据库迁移，而是在不遵守Rails规范的单独文件夹下使用原始SQL脚本(以及稍后使用SQL视图和函数)。

我的问题是，如果我刚开始发展我的应用程序，我是否应该担心这些事情。显然，这本书建议我避免将来可能出现的问题，而我的.NET开发人员也想同意，但是我的Rails开发人员(还是个婴儿)告诉我，因为我还在学习框架和Ruby，所以要100%遵循"Rails方式“。我想知道，到底有多少成功的Rails应用程序遵循了app/模型中所有模型的规范，应用程序/控制器中的所有控制器都没有进一步的隔离，有多少种是“企业级”架构？

Answer 1

如果你只是在学习Rails，我会采用Rails的方式(“在罗马的时候……”)。如果您担心您的创业可能会因为未来的可伸缩性问题而步履蹒跚，我建议您重新考虑使用RoR的决定。在您熟悉的环境中，解决可伸缩性问题已经够困难的了，当您处于困境中时，您不想与不熟悉的问题搏斗。(请注意，这并不是Ruby特有的，它同样适用于Python、Scala、Perl、C++或其他您不知道的语言.)

Answer 2

无论幸运与否，Rail还没有为企业应用程序做好准备。我的一个朋友试图强迫它遵循企业模式和最佳实践，但事实是，模型与持久性模式紧密相连。在“真”企业应用程序中，视图和控制器使用的模型与一个称为域模型的单独模型进行了交谈。这包含域或业务逻辑，并连接到持久层。由于Rails不允许这种分离(我知道您可以使用Rack来伪造这个，但这并不简单)，所以它显然没有做好企业准备。

也就是说，Rails非常适合于“小”应用程序(在这种情况下，小应用程序是非常相关的)。

另外，我的朋友确实尝试过使用Rails 3，发现它在使企业做好准备方面取得了许多进展，但还没有完全实现。

Answer 3

相信你所说的“企业”是什么意思吧。你期望有多少模型和控制器？我已经开发了大约30个模型文件和10-15个控制器的应用程序，没有遇到任何问题，但我可以想象，如果您有数百个，它可能会更难管理。

但即便如此，也有一些解决办法(例如插件)。