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，也就越来越难于适应需求的变化。