Ruby on Rails 的限制是什么？

Question

我记得曾经和一些使用Ruby on Rails的人交流过，他们在遇到限制或发现它过于严格时不得不放弃使用。具体细节我已经忘记了，但可能与使用多个数据库有关。

因此，我想知道哪些功能/要求超出了Ruby on Rails的范围，或者至少需要进行一些扭曲，以至于最好使用另一个更灵活的框架，即使你可能会失去一些优雅或编写额外的样板代码。

- mish

---

听起来很主观。 - S.Lott

Answer 1

Rails（不是Ruby本身）自豪地被称为“有见解的软件”。

实际上，这意味着rails的作者们以一定的目标受众为依据（基本上是他们自己），专注于rails的开发。如果某个功能对于目标受众来说不是必要的，那么它就不会被添加到rails中。

下面是我能想到的rails明确不支持但可能会引起关注的功能：

1. 数据库中的外键
2. 同时连接多个数据库
3. SOAP web服务（从rails 2.0开始）
4. 同时连接多个数据库服务器

即便如此，通过插件扩展rails非常容易，而且有很多插件可以将上述所有功能添加到rails中，甚至还有更多其他功能，所以我并不认为这些是限制。

唯一需要注意的是，rails是围绕着使用MVC创建CRUD Web应用程序的理念构建的。如果你正在尝试做一些不是CRUD Web应用程序的事情（例如Twitter，实际上是一个消息系统，或者你疯了想使用像ASP.NET WebForms这样的模型），那么你也会遇到问题。在这种情况下，最好不要使用rails，因为你基本上是在试图用自行车部件造船。

实际上，你遇到的不能只使用一个快速插件或者一两天的编码就能解决的问题，都是与底层C Ruby运行时相关的固有问题（如内存泄漏、绿色线程、性能差等）。

- Orion Edwards

---

现在Rails已经原生支持连接到数据库/多个数据库服务器。这可以在模型或每个请求的基础上进行设置，由你来决定。我现在正在使用它-在本地主机上有一个postgres，以及在公司BigFreakingOracleBox上运行的一个Oracle数据库，没有任何问题。 - Patrick McKenzie

没有支持外键？/ 我看看日历……这些人觉得自己身处什么年代？ - Randal Schwartz

它支持外键，只要它们是id列。 - Alan Hensel

它支持外键！当然，它对过多的数据库逻辑持有自己的观点，并且在迁移文件中没有内置的辅助程序来添加键约束，但是您可以非常容易地添加它们： execute "alter table people add constraint..." ，它能正常工作。 - Andrew Vit

2. 和 3) 都是不正确的 - 您可以轻松连接到多个数据库和数据库服务器。

- Tilo

Answer 2

Ruby on Rails默认不支持两阶段提交，如果您的应用程序需要保证即时一致性并且需要使用两个或更多数据库模式，则可能需要使用两阶段提交。对于许多Web应用程序而言，我想这不是常见的用例。可以使用两个或更多的数据库来支持最终一致性，也可以使用一个数据库模式来支持即时一致性。前一种情况是一个伟大的问题，如果您的应用程序必须支持大量的交易（请注意技术术语:)。后一种情况比较典型，而Rails表现得非常好。

实际上，在真正的可扩展性问题出现之前，我不会担心使用Ruby on Rails（或任何框架）。首先构建一个厉害的应用程序，然后再考虑可扩展性。

澄清：我指的是Rails难以支持的事情，因为它可能需要在架构上进行根本性的转变。我将慷慨地包括某些作为gem/plugin生态系统的东西，例如外键强制执行或SOAP服务。

在这里，"两阶段提交"指的是试图在一个事务上下文中向两个物理不同的服务器进行两个提交。

两阶段提交的用例＃1：您已经将数据库分组，因此您有2个或多个数据库服务器，并且您的模式分布在两个服务器上。您可能希望提交到两个服务器，因为您希望允许ActiveRecord进行"外键映射"，跨越不同的服务器。

两阶段提交的用例＃2：您正在尝试实现消息传递解决方案（很抱歉，我是一名J2EE开发人员）。消息生成器将消息提交到消息代理（一个服务器）和数据库（另一个服务器）。

- Alan

---

虽然从技术上讲这是正确的，但我认为您可以使用数据库中间件来实现两阶段提交，或者只需使用支持它本身的数据库即可正常工作。我不确定是否应将其称为限制，也许只是框架中不是优先考虑的事项。 - PJ.

在这个例子中，你所说的“2阶段提交”是什么意思？ - Orion Edwards

Answer 3

我也发现了一些关于ActiveRecord限制的好讨论。

- mish

Answer 4

我认为这里有一个更大的“元问题”，可以回答，即“何时使用外部库来加快开发时间才是可以接受的？”

第三方库通常很棒，可以显着减少开发时间，但存在一个主要问题，Joel Spolsky称之为“泄漏抽象法则”。如果您在Google上查找，他的文章将首先出现。基本上，这意味着开发时间的权衡意味着您不知道底层发生了什么。因此，当某些东西出现问题时，您完全会被卡住，并且具有非常有限的调试方法。这还意味着，如果您遇到RAILS中不支持的必需功能，则除了自己编写该功能（如果您很幸运）外，没有下一步可走的方法。许多库可以使此操作变得困难。

我们在我的开发商店中遭受了这个问题的严重打击。我们的解决方案在正常负载下运行良好，但是我们发现，我们使用的第三方订阅库根本无法经受住我们的网站开始拥有大量并发用户后所经历的负载。这使我们处于非常困难的境地；基本上，我们必须考虑性能重新编写整个订阅服务。这样做意味着我们浪费了使用库所花费的所有时间。

第三方库对于小到中型应用程序非常有用；它们可以大大减少开发时间，并隐藏那些在开发早期不必处理的复杂性。但是，最终它们会追上你，你可能不得不重写或重新设计解决方案，以克服“泄漏抽象法则”。

- joebasirico

---

当然，使用现有库的经验有助于教会你实际需要编写什么。因此，这并不是完全的损失。坦白地说，我在编写任何东西时都以最终的性能为目标，并嘲笑那些认为硬件总会追上来的傻瓜... - Richard T

Answer 5

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

- Jeet

Answer 6

Orion的回答是正确的。在AR/Rails中几乎没有硬性限制：部署到Windows、不常用的AR连接器，例如Firebird等。即使是他提到的多个数据库和DB服务器，也有适用于遗留系统、分片和其他原因的宝石（gems）和插件来解决这些问题。

真正的限制在于跟上Rails开发人员正在进行的所有事情并持续研究特定问题是多么耗费时间，考虑到博客的数量和邮件列表的体量。

- Gene T