Rails案例研究

　　* ActiveRecord 利用类名的复数形式来推出表名。

　　* 主键的名称为 id。

　　* 列表的排序顺序由 position 字段决定。

　　对象关系映射是使用遗留模式（可能定义时没有考虑对象模型）时的最佳解决方案。但是当您能为应用程序显式地设计数据库模式时，您通常不需要映射框架了。我们将 ActiveRecord 看作我们的一个巨大优点。我们可以包含关系数据库，需要时转入 SQL 并在适当的时候退出。

　　迁移

　　Rails 迁移使我们能够用代码表示模式的两个版本之间的差别，和它们所包含的数据之间的差别（请参阅文章 “Rails 迁移”）。对每个迁移都进行了命名和编号。可在任何时候恢复到任何版本。迁移有以下一些确切的优点：

　　* 产生错误代码时可恢复到一个旧版本的模式。

　　* 用代码而不是 SQL 来表达模式，更便于我们使用。

　　* 在最大程度上与数据库独立。

　　但是迁移也有一些限制。如果两个开发人员同时创建迁移，则编号会出现混乱，所以我们必须手动处理。我们通过有效的通信来使这些问题最小化：团队成员构建需使用迁移的新模型时发出通知。但是这个模型依赖于团队的开发人员较少或迁移进展较慢的情况。

　　ActiveRecord 还有其他的限制，其中一些是故意作出的。Rails 的创建者认为：数据库的约束和组成应归入应用程序而不是数据库，这种思想带来了一些副作用。ActiveRecord 使用视图的情况不是很好：构建过程（克隆模式、复制测试数据并运行测试）并不能正确地进行复制。ActiveRecord 在使用参考完整性约束的某些场合也会出现问题，因为某些类型的关联可能连接到多个数据库表。跨越复杂模型进行预先加载很复杂，通常在连接多行时需要使用 SQL。继承也受到限制：使用 ActiveRecord 时，我被迫使用单表继承 映射策略，而该策略并不总是最佳选择。（参见 参考资料）

　　所有的持久性策略都充满了妥协。我认为 ActiveRecord 实现了一组有效的妥协，常常选择了简单性。总而言之，ActiveRecord 和迁移是我们的积极推动。我们可以快速地构建解决方案，我们拥有足够的 SQL 访问权可在需要时改进系统性能。但是当 ActiveRecord 并不总能应对挑战时，最好将 Rails 应用于使用老旧模式的项目。一些替代的持久性模型正在出现，包括 RBatis，一种 iBATIS Java 框架的端口（参见 参考资料）。现在讨论 RBatis 的有效性还为时过早。

　　结束语

　　对于我的团队和项目来说，Ruby on Rails 被证明相当有效。我还不知道这个项目的最终规模如何，因为撰写本文时该系统才运行 3 个月。现在只是开始增加通信量。但是我们对生产力却很了解。我知道团队的预算比竞争公司（这些公司常常使用 Java 解决方案）的要低得多。我对我们的生产力也很有信心。

　　通过跨越边界 系列，我向您介绍了 Java 领域以外的语言和解决方案。但程序员毕竟是技术人员。每个高明的技术人员的工具包中都应包含适用于每个解决方案的广泛的工具集。除工具外，本系列中介绍的观点也为您展示了一些其他思路。现在一些框架设计者甚至将 Seaside、Rails 中的技术甚至 JavaScript 应用于 Java 框架中。找机会进行同样的应用，继续 “跨越边界”。