RoR 中,对 Active Record 模式的实现完全利用了 Ruby 语言的灵活性,简短几行代码就可以定义一个关联。并且通过复杂的 ActiveRecord:Base 对象,提供了 CRUD(创建、读取、更新、删除)操作的默认处理。所以使用 RoR 时,绝大部分常见的数据库操作只需要很少量的代码就可以完成,大大提高了开发效率。
但 Active Record 模式也不是完美的,Active Record 存在不少缺点。
* Active Record 模式需要数据表结构和对象属性一一对应(至少是大部分对应),否则将难以使用 Active Record 模式; * Active Record 模式并不能够真正适合完全面向对象的应用程序。因为 Active Record 模式本质上就要求一个对象必须和一个数据表对应。但在完全面向对象的应用程序中,数据和操作数据的方法很可能分布在各个不同的对象中,这些对象却并没有和 某一个数据表完全对应,而且 Active Record 无法很好的处理对象的继承、聚合等面向对象常见的对象间关系; * 随着逐渐向 Active Record 添加业务逻辑,Active Record 对象中会混入越来越多的 SQL 语句,这在更复杂的项目中显然是一个不利因素。
如果在 Active Record 模式中添加了对数据关系(注意,不是对象关系)的处理,那么还要注意性能问题: 假如一个 Active Record 对象有多个关联。那么我取出一个对象时,很可能就连带取出了其他不少对象。但这些对象可能根本就是本次操作用不上的。其次,将对象更新到数据库时,也需要对关联的对象进行处理,否则对关联对象的修改就会丢失。
虽然可以用各种技巧来避免这些情况,但毫无疑问需要开发者对 RoR 的 Active Record 很熟悉才行。否则看上去很简单的代码,背后则会是噩梦般的数据库操作。
其次,假设我们要将数据库中每本书的单价减半,那么采用 Active Record 模式时,就必须首先读取所有的记录并实例化为对象,然后更新对象属性,再写回数据库。可想而知这样会有多差的效率。 当然了,实际开发中没有人会这样做。开发者会编写一个单独的方法,用一条 SQL 语句完成对批量数据的更新。但也说明 Active Record 模式不适合批量处理数据,而现实世界中,批量处理数据的需求随处可见。
不过由于 RoR 对开发效率戏剧性的提高,所以对于追求开发效率的项目,RoR 是一个很不错的选择。而且性能上的不足可以通过更新硬件或者配合其他技术手段来改善(例如 FastCGI 通常是运行 RoR 应用的首选)。因此在现实世界中,37signals.com 公司的所有基于 RoR 开发的应用,都获得了良好的性能表现(但是同等的硬件,跑 PHP 开发的同样功能应用是更好还是更差呢?这个问题没有答案)。 Active Record 与 ORM