关于Domain Model的对谈录之四: 充血与贫血的折衷

A:持久化的问题搞得充血模型很头痛。于是有人提出了一个折衷的模型,即
与持久化无关的业务逻辑放到Domain Object中,有关的逻辑则放到Transaction Script中。robbin对种模型有非常好的阐述,这种模型的可操作性也的确比较强。

B:嗯,其实以前我也一直是这样做的。不过,这种模型还可以再精化一下,就是
尽量在Domain Object中做好所有的业务逻辑,然后Transaction Script只处理持久化。具体来说,就是先通过Transaction Script取出所有相关Domain Object,然后让这些Object在内存中互相交互,互相改变状态,以及产生新对象,最后再通过Transaction Script对这些新旧对象进行持久化。

A:听起来不错哦!职责分离的比较清楚,Domain Object和Transaction Script各司所长。你实践起来怎么样?

B:
折衷模型在大多数情况下都很好,因为大部分业务逻辑的OLTP处理都只牵涉到少数的Domain Object,因此在Transaction Script中对它们进行CRUD都不会很占用过多篇幅,代码整体上还是很简洁的。

A:那在少数情况下呢?

B:很讨厌。目前按我的经验有两种情形让我很烦:

   1.
如果参与处理Domain Object的类型有很多种,折衷模型就会很可笑。如果你的Script中要一次性取出很多种对象,那么其中很多种对象对你来说可能都是远亲,你的Script本不应该去找它们的。但你却找它们了,这意味着IOC被严重破坏,代码的质量可想而知。

   2.
如果参与处理的Domain Object实例数很多,折衷模型还会遭遇性能问题。比如一个批量操作,正常流程是取一个做一个,然后立即更新到数据库,对象从内存中清除;但现在你要取一整批,然后做一整批,最后再批量更新到数据库,这不是内存老虎是什么?很可怕的!

A:很好! 那遇到这两种情况你怎么办?

B:能怎么办?只能干脆把业务逻辑全部从Domain Object里转移到Transaction Script中来,这样首先可以避免性能问题(做一个存一个),而且还可以通过多个Script对象之间的协作来完成复杂的业务逻辑。

A:但这就完全退化到了贫血模型了。

B:是啊。所以,还是干脆点,就用充血模型好了。

A:呵呵。不管怎么样,从你上面举的例子中可以看出,
业务逻辑越复杂,Domain Model的性价比就越高

B:为什么?

A:因为业务逻辑越复杂,一次业务计算牵涉到的业务对象的种类和实例数就会越多,Transaction Script就会变得越来越全能,也越来越臃肿(反IOC),也就越来越反OO,也就越来越难于适应需求的变化。

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.