ruby on rails 的限制是什么？答案

【问题标题】：What are the limits of ruby on rails?ruby on rails 的限制是什么？
【发布时间】：2010-09-15 20:51:27
【问题描述】：

我记得我曾与那些使用 Ruby on Rails 的人交谈过，但当他们遇到限制时不得不放弃它，或者发现它最终过于死板。我忘记了细节，但可能与使用多个数据库有关。

所以我想知道的是 Ruby on Rails 之外的特性/要求，或者至少需要这样的扭曲，最好使用另一个更灵活的框架，即使你可能不得不失去一些优雅或编写额外的样板代码。

【问题讨论】：

对我来说听起来很主观。

标签： ruby-on-rails ruby

【解决方案1】：

Rails（而不是 ruby 本身）以成为“有意见的软件”而自豪。

这在实践中意味着 Rails 的作者有一定的目标受众（基本上是他们自己），并专门针对该目标受众。如果该目标受众不需要 X 功能，则不会添加它。

在我的脑海中，rails 明确不支持人们可能关心的事情：

数据库中的外键
一次连接到多个数据库
SOAP Web 服务（自 rails 2.0 起）
一次连接到多个数据库服务器

也就是说，使用插件扩展 rails 非常容易，并且有一些插件可以将上述所有功能添加到 rails 等等，所以我不会将这些视为限制。

唯一需要注意的是，rails 构建是围绕使用 MVC 创建 CRUD Web 应用程序的想法。如果您尝试做一些不是 CRUD Web 应用程序的事情（例如 twitter，它实际上是一个消息传递系统，或者如果您很疯狂并且想要使用像 ASP.NET Webforms 这样的模型），那么您也会遇到问题。在这种情况下，您最好不要使用铁轨，因为您实际上是在尝试用自行车零件建造一艘船。

您遇到的问题很可能无法通过快速插件或一两天的编码来解决，这些问题都是底层 C Ruby 运行时的固有问题（内存泄漏、绿色线程、垃圾性能等）。

【讨论】：

鉴于我们正处于拥有超过 1 个 Ruby 运行时可供选择的边缘，甚至其中一些问题也变得毫无意义。
Rails 现在支持直接连接到 DB/多个 DB 服务器。（根据每个模型或每个请求，您的电话。）我现在正在使用它——在 localhost 上运行一个 postgres，在 BigFreakingOracleBox 公司上运行一个 Oracle DB，没有任何问题。
不支持（喘气）外键？ /me 查看日历...这些人认为他们处于哪个年代？
它支持外键，只要它们是 id 列。
支持外键！当然，它反对过多的数据库逻辑，并且没有用于在迁移文件中添加关键约束的内置帮助程序，但您可以非常轻松地添加它们：execute "alter table people add constraint..." 并且它可以工作。

【解决方案2】：

Ruby on Rails 不支持开箱即用的两阶段提交，如果您的数据库支持的应用程序需要保证即时一致性并且您需要使用两个或更多数据库架构，则可能需要这样做。

对于许多 Web 应用程序，我敢说这不是一个常见的用例。一个人可以很好地支持两个或多个数据库的最终一致性。或者可以支持与一种数据库模式的即时一致性。如果您的应用程序必须支持大量事务（请注意技术术语:)，则前一种情况是一个很大的问题。后一种情况比较典型，Rails 也可以。

坦率地说，在您遇到真正的可伸缩性问题之前，我不会担心使用 Ruby on Rails（或任何框架）的限制。首先构建一个killer应用程序，然后再考虑可扩展性。

澄清：我正在考虑 Rails 很难支持的东西，因为它可能需要对其架构进行根本性的转变。我会很慷慨，包括一些属于 gem/plugin 生态系统的东西，例如外键执行或 SOAP 服务。

所谓两阶段提交，是指尝试在一个事务上下文中对物理上不同的服务器进行两次提交。

用于两阶段提交的用例 #1：您已经对数据库进行了集群化，因此您拥有 2 个或更多数据库服务器，并且您的架构分布在这两个服务器上。您可能想要提交到两台服务器，因为您想让 ActiveRecord 认为做一个遍历不同服务器的“外键映射”。

用于两阶段提交的用例 #2：您正在尝试实现消息传递解决方案（抱歉，我白天是 J2EE 开发人员）。消息生产者向消息代理（一台服务器）和数据库（另一台服务器）提交。

【讨论】：

虽然这在技术上是正确的，但我相信你可以使用 db 中间件来实现两阶段提交，或者只使用一个本身支持它的 db 并且它会正常工作。我不确定我是否称其为限制，也许只是框架的优先事项。
在此示例中，您所说的 2 阶段提交到底是什么意思？

【解决方案3】：

还发现了一些关于limits of ActiveRecord 的好讨论。

【讨论】：

【解决方案4】：

我认为这里有一个更大的“元问题”，可以回答，那就是“什么时候可以依靠外部库来加快开发时间？”

第三方库通常很棒，可以大大缩短开发时间，但是有一个主要问题，Joel Spolsky 称之为“抽象泄漏定律”。如果您在 Google 上查找，他的帖子将首先出现。从本质上讲，这意味着开发时间的权衡意味着您不知道幕后发生了什么。因此，当出现问题时，您会完全陷入困境并且调试方法非常有限。这也意味着，如果您遇到了 RAILS 中根本不支持的功能之一，而您确实需要，那么您将没有下一步，除非您自己编写该功能，如果您幸运的话。许多图书馆都让这变得困难。

这个问题让我们在我的开发商店里受到了严重的影响。我们的解决方案在正常负载下运行良好，但我们发现我们使用的第三方订阅库根本无法承受我们网站开始获得大量并发用户时所经历的那种负载。这使我们处于一个非常困难的境地；本质上，我们必须自己重写整个订阅服务，同时考虑到性能。这样做意味着我们浪费了使用库的所有时间。

第三方库非常适合中小型应用程序；它们可以大大减少开发时间并隐藏在开发的早期阶段不需要处理的复杂性。然而最终他们会赶上你，你可能不得不重写或重新设计你的解决方案以超越“泄漏抽象法则”

【讨论】：

...当然，您使用该预先存在的库的经验帮助您教会了您真正需要编写的内容。所以，这不是完全的损失。坦率地说，我写下我所接触到的所有东西时都考虑到了终极的性能，并嘲笑那些说硬件总会赶上来的傻瓜......

【解决方案5】：

Ruby 没有像 ASP.Net 中的 IsPostBack 这样的功能

【讨论】：

【解决方案6】：

猎户座的答案是正确的。 AR/Rails 几乎没有硬性限制：部署到 Windows、不常用的 AR 连接器，例如Firebird, )，但即使是他提到的东西，多个数据库和 DB 服务器，也有一些 gem 和插件可以解决遗留问题、分片和其他原因。

真正的限制是，在考虑到博客数量和邮件列表数量的情况下，掌握 Rails 开发人员正在处理的所有事情以及研究特定问题是多么耗时。

【讨论】：