为什么把持久化放到Domain Object是不OO的.

    争论会一直在人群中存在,它消失就代表人类文明也灭亡了...

    很久以前,在园子曾经出现过关于ORM的争论.而就是在那段时期,我对OO及ORM的概念在硝烟弥漫的文字里逐步建立起来.最近对于是不是该把持久化放入到book的讨论,我想跟之前的ORM争议颇有相似之处.

    说到ORM,大家应该会赞成信息系统的开发,可以分为以数据库为中心、和以OO为中心的两种主要方式吧.

    1.以数据库为中心.显而易见,开发的初期会先设计好数据库结构,包括表/字段/关系基于存储过程等等对象.然后再依据数据库来做上层的业务逻辑,以及表现层等等.按照这种方式开发的系统,其实Domain Object已经没有存在的必要了.你完全可以在aspx.cs文件中开一个datareader读出数据库的内容再显示出来.而其实所谓强类型的数据集,其实就是物理数据库在内存中的一个映射.业务实体等这些东西是没有必在的必要性的.

    2.以OO为中心来设计系统.首先第一步是设计业务流程和实体类,然后再根据需要来设计数据库结构等,在实体类和数据库中间再用ORM桥接起来.对以OO为中心的设计来说,在设计时间,业务流程/逻辑/实体类这些才是中心要点所在,在初期甚至设计的主要阶段,数据库/持久化这些等等东西都是不会被优先考虑的.在这个立场上来看,持久化是因为内存太小,电脑会掉电才不得不需要的东西.而在后期数据将会被持久化到哪里,还并不是一个十分确定的问题.

    另我找到一篇贴子,是讲Martin Fowler的贫血模型和rich domain object(不敢乱翻)的.个人觉得讲得不错.里面的第一种就类似于以数据库为中心的一种方式,贫血模型下的实体除了能提供强类型外,并没有带来多余的价值;第二种也就是Martin Fowler提倡rich domain object.可以看到 Item 实例了一些业务逻辑,然后最后的持久化是由ItemManager来完成的.原文也提出了在Item中不应依赖于ItemDao.

    最后该文还有提到第三种方法,这种方式与之前亚历山大同志提出的在book.Save中实现对象的自我持久化很相似.

    对于这种方式,我并没有要否定它的意思.可是,这种方式怎么能算是OO呢?如果你是以OO的方式来设计系统的话,在设计实体类的时候怎么会考虑到持久化这个问题呢,是不是在这一点上就已经偏离了OO的理念?

    需要厘清的是我本人认为实体类应该实现一定的业务逻辑,类似于亚历山大同志提出来的Man需要Borrow和Lend方法的例子.而非常不赞同的是亚历山大同志提出来的在Book中实现持久化方法Save是一种很OO的设计.

    而令我十分困惑,明明Book.Save实现持久化的话,那就意味着Book对象对持久层产生了依赖.怎么还有那么多人说这是解耦!非常地困惑啊!