什么是ActiveRecord

ActiveRecord是什么:1. 每一个数据库表对应创建一个类.类的每一个对象实例对应于数据库中表的一行记录; 通常表的每个字段在类中都有相应的Field;2. ActiveRecord同时负责把自己持久化. 在ActiveRecord中封装了对数据库的访问, 即CRUD; 3. ActiveRecord是一种领域模型


说实话,从去年开始用SubSonic, 我就一直有点困惑, 什么是ActiveRecord, 什么不是ActiveRecord, 以及应该怎么样使用它才对. 把我的一些想法写下来, 希望能和大家交流.

ActiveRecord是什么:
1. 每一个数据库表对应创建一个类.类的每一个对象实例对应于数据库中表的一行记录; 通常表的每个字段在类中都有相应的Field;
2. ActiveRecord同时负责把自己持久化. 在ActiveRecord中封装了对数据库的访问, 即CRUD;
3. ActiveRecord是一种领域模型(Domain Model), 封装了部分业务逻辑;

ActiveRecord不是什么:
1. Row Data Gateway
Row Data Gateway模式中每个对象也封装了数据库记录的状态和持久化到数据库的访问方法; 这两个有时候很难区分. 细微的区别在于Row Data Gateway不封装任何业务逻辑;

2. TableGateway
TableGateway是一种数据访问模式, 对每个表有一个类, 类的方法封装了对单个表的数据操作, 如CRUD; 方法的接受表字段的值作为参数;
比如说对表Person有DAOPerson, 有以下方法:
int Create(string name, bool isMale)
DataSet Find(int personId)
void Delete(int personId)
void Update(int personId, string name, bool isMale)
微软的很多代码示例中使用了此模式;

ActiveRecord的区别在于ActiveRecord的对象中保持了记录的值, 是有状态的, 而TableGateway是没有状态的, 只是一系列数据库访问方法的集合;

3. Table Module
Table Module是一种领域逻辑模式, 一个类对应于数据库中的一个表; Table Module通常和Table Gateway合作, 前者负责基本的业务逻辑, 后者负责数据库访问, 以达到逻辑层和持久化层的隔离; 微软的实例代码经常使用这两者, 如对表Person, 通常会定义两个类, PersonBL和PersonDB, 在PersonBL中处理验证等逻辑, 并调用PersonDB访问数据库, 层间调用使用DataSet或自定义数据传输对象传输数据

在业务逻辑比较简单并且有和表的一一对应时, ActiveRecord相对来说更简单, 因为它在一个类中包括了业务逻辑对象和数据访问, 而且不需要数据传输对象, 减少了维护的工作量;
和Table Module比较起来, ActiveRecord与数据库耦合更紧;

ActiveRecord适用于:
1. 业务逻辑比较简单;当你的类基本上和数据库中的表一一对应时, ActiveRecord是非常方便的, 即你的业务逻辑大多数是对单表操作;

2. 当发生跨表的操作时, 往往会配合使用事务脚本(Transaction Script), 把跨表事务提升到事务脚本中;

3. ActiveRecord最大优点是简单, 直观; 一个类就包括了数据访问和业务逻辑. 如果配合代码生成器使用就更方便了;

4. 这些优点使ActiveRecord特别适合web快速开发, 而正是快速开发框架ROR采用了ActiveRecord, 并且很多类ROR框架如Castle的纷纷效仿才使ActiveRecord重新进入大家视线;
我想这也是为什么Martin Fowler在PoEAA中早就提出了这个模式, 但是直到最近两三年ActiveRecord才热起来可能就是这个原因;

ActiveRecord不适合于
1. ActiveRecord虽然有业务逻辑, 但基本上都是基于单表的. 跨表逻辑一般会放到当发生跨表的操作时, 往往会配合使用事务脚本(Transaction Script)中. 如果对象间的关联越来越多, 你的事务脚本越来越庞大, 重复的代码越来越多, 你就要考虑Domain Model + O/R Mapper了;

2. ActiveRecord保存了数据, 使它有时候看上去像数据传输对象(DTO). 但是ActiveRecord有数据库访问能力, 不要把它当DTO用. 尤其在跨越进程边界调用的时候, 不能传递ActiveRecord对象;

Feedback
2008-05-09 11:04 by 怪怪
不错， 很准确， 赞一个。

另外， 这个模式只是在POEAA中介绍过， 并非Fowler提出的(其实Fowler这辈子， 基本没提出过什么自己的东西)； 这种用法也早就普遍存在了， 只是最近一热炒， 就被人为放大了。

不过我个人认为，ActiveRecord虽然提供了便利性， 同时也会带来思维方式和实践方法上的禁锢和负面影响， 所以并不总是提高， 有时也会降低生产效率。这是因为从根本上讲， 有时候我们并不真的需要一个有着固定接口的对象或者类。

回头说到SubSonic， 说实话其作者可能比园子里一些做框架的同志水平还菜很多， 但是SubSonic在很多场景下确实轻量、好用， 这反而是我们的同志应该好好思考的了。
2008-05-09 11:56 by wanghualiang
@怪怪
为什么说作者水平菜？
是代码写的有问题还是架构不是很合理？
没看过源码，但用在项目上了，很简单很好用。
2008-05-09 12:26 by jackyw [未注册用户]
SubSonic提供了很好用的代码生成工具，框架也比较轻量级
是比较好的实现了ActiveRecord模式的框架2008-05-09 12:56 by lovecherry      
在SubSonic之前也看到过buildprovider做orm的demo，但是SubSonic对作者把它做成了产品
#7楼 [楼主]   回复  引用  查看    
2008-05-09 13:37 by kuber      
@怪怪
任何方法都有其要解决的问题域, 我想是因为最近两年Web 2.0热导致的快速的web应用开发大行其道使ActiveRecord被重新注意了.

另: 好久没有看见怪怪有新的文章了. 我很喜欢"闲言碎语"这篇文章. 不过里面好像还有很多未竟之言, 我还等着下文呢.
2008-05-09 13:44 by designbeauty
第一次听见有人说Rob菜的。。。，那正常的人应该是什么水平。
btw. subsonic真的很好用很强大。 楼主可以分享一下经验
2008-05-09 15:10 by 怪怪      
@金色海洋（jyk）
没时间啊...， 而且感觉江郎才尽， 白活不出什么有价值的内容了。 倒是今天早上无缘无故的感觉到一阵喜悦， 似乎有些事更明白了， 但暂时又说不清楚明白了什么。 反正接触的东西越多， 感觉需要学的东西和需要做的工作就更多了。

@kuber
嗯， 可以这么说。 不过其前提是在面向对象或者基于对象的设计和实现方式下。 我对AcitveRecord、 Row Data Gateway、 DTO等等一些方法的质疑， 实际上更多的是针对面向对象的一些痼疾了。

比如就这种CRUD较多的场景， 不采用这些方式， 很显然光写代码时的类型转换， 和数据字典存取的安全性和便捷性， 就够我们一呛。 而采用这些方式呢， 通过对象我们就得到了一组固定的接口， 要么接口太多， 要么接口太大， 且不说什么性能和维护的问题， 损失掉的灵活性和直接性也非常可惜； 如果再通过新增接口去适配不同的场景， 除了显配一下自己的面向对象功力， 很多时候只是徒增麻烦。

只是我也仅仅在探索阶段， 说些怪话的目的只是抛砖引玉， 呼吁大家一起来看看有啥新的路子没有， 而不是局限于过去那些旧的观点和争论。那篇文章之所以写不下去了， 关键是在现有的语言框架下， 我还没找到能完全满足我的想法的设计和表达方式， 感觉还需要琢磨一阵子。 如果仅仅是一些小的改进， 感觉说起来也没啥意思~

@designbeauty
呵呵， 菜不菜的也要看那些方面。 我是指对概念的理解和掌握的技巧这两方面。 我看过他的一些Video， 说实话此人对很多概念是相当的模糊； 也用过和改过一阵子SubSonic，这个东西涉及的技巧也绝对比不上园子里一些高手的东西。

不过就像@lovecherry说的， 人家在做产品这一块， 可一点也不菜， 我还是相当的佩服的。另外， 去你网站看了， 很漂亮啊， 至少我很喜欢这种风格， 唉感觉设计还是比技术需要更多的天赋。
2008-05-09 16:34 by good man      
其实在这里我们应该对别人多鼓励,不能说菜不菜,你应该
把别人的错误找出来,达到共同学习,一起进步啊
2008-05-09 16:37 by RicCC      
ActiveRecord的主要优点是一个过渡模式，当你没法从失血一步走到充血模型，或者不大确定是否该这样做时，是一种比较好的选择
另外就算使用充血模式的复杂项目，还是会存在很多适合ActiveRecord的对象
我想当你ActiveRecord使用熟练之后思路应该会不大一样，选择范围会比较开阔

2008-05-09 17:07 by 怪怪      
@good man
哈哈， 这不是个老外吗， 他又不会跑博客园来， 跑来也不认识中文～ 另外， 我一向对名人比对咱一般的兄弟要求严格的多， 可以说刻薄了~

@RicCC
写的比较乱， 重新编辑一下， 两点：

1. 在面向对象这个大前提下， AcitveRecord、 Row Data Gateway、 DTO等形式是否是必要的。

是不是一定要将数据包裹以任何一种形式的对象的方式来处理， 我觉得也是可以有多种判断方式的； 比如对于最简单的CRUD系统，或许可以根据在于我们在展示与持久之间， 需要（比如各种逻辑包括业务逻辑产生的）手工编码操作数据的次数（和工作）来进行选择？ 如果在其它地方下功夫（如操作和流程的自动化），可以使得没有对象化而导致的问题小于一个限度， 我们也许就没有必要对象化。

这个问题的根本在于首先要确认我们手头的这个活儿，是否在大模型（不是我们常说的模型）上真的需要将数据对象化， 还是可以用其它模型更好的解决。

2. 如果其实现的核心不是面向对象特性， 比如说利用FP的特性， 或者在支持TMP的语言里。

如果我能得到使用某一方式方法的一切好处， 避免它基于面向对象实现时的缺陷， 根据其特征， 也许各种方式方法还可以分别叫做 AcitveRecord、 Row Data Gateway、 DTO， 但由于不再带有面向对象令人不爽的阴暗方面， 那么也许进行选择和判断就容易的多。

如果能够做到， 而且成本很低， 那么也许我们可以忽略这个问题， 长期的按一定规则使用某些方式方法， 这样就可以更加集中注意力解决其它问题。