Transaction Script 、 Doamin Model、Logic SQL
12/6/2004于珞珈山
一、故事的开端
我以前没关注过Domain Model、也不知道什么叫Transaction Script以及它和Domain Model的是是非非。对我来说,一切都是因Martin Fowler的一篇文章而起。
2003年11月,Martin Fowler 拖着Eric Evansv(Domain-Driven Design权威,也是《Domain-Driven Design: Tackling Complexity in the Heart of Software》一书的作者)发表了一篇题为《AnemicDomainModel》的战斗檄文。这块石头还真激起不小的浪,很多人开始关注、思考Transaction Script、Domain Model的问题。其实,在此之前,Martin写过一篇《Domain Logic and SQL》说Transaction Script的劣处。
在继续阅读本文之前,建议你先通过上面的相关链接,了解事情的始末。
二、什么是Transaction Script、 什么是Domain Model
事实上,Martin的《Domain Logic and SQL》一文针对Transaction Script、Domain Model、Logic SQL,从程序的复杂度、性能、可扩展性、可移植性、可测试性等方面做了非常详细的对比。
三、我的分析和结论
我个人是不同意Martin的RichDomainModel。因为,我觉的,RichDomainModel往往,特别是在数据应用系统中,根本没有反映现实世界的情况。不是说,对象都需要含有数据和动作的。譬如,一个银行Account的转帐,按Martin的思路,建模时,应该为类Account添加withdraw(long mount)这样的成员函数,但是,很显然,银行Account反映到现实世界,应该是银行帐户本的一条记录,它只是一个信息载体,没有自发动作,withdraw应该建模到譬如AccountManger这样的类中。Account和Person这样的抽象不同,Person在现实生活中,本来就有自发动作,譬如say(String words)。
当然,不可否认,从Martin的《Domain Logic and SQL》一文,你可以看到,采用RichDomainModel,的确有不少的好处。但是,不代表因为RichDomainModel带来的那些好处,就说它是正确的思路。
我的个人看法:Martin不以为然的所谓TransactionScript方法事实上是真正反映现实的,是自然OO建模的结果。而RichDomainModel虽然带来一些编程、架构上的好处,但是它是畸形的。
这里,我还想强调的是,采用不同的技术,采用RichDomainModel体现的优势是不同的。譬如,你使用Hibernate持久化,那么它的优势几乎就没有了。
四、目前,我在实际开发中比较普遍采用的技术和架构(适用于中小型数据应用)
|---->跨DataServices的服务(Transaction/Not Transaction)
Presentation---->Façade-- |--->DataServices------>Hibernate------->DB
|---->and so on
两点说明:
1、DataServices、跨DataServices的服务,它们的具体实现根据后者是否要求被调用的所
有DataServices在同一事务中决定。如果,后者的确有这个要求,采用LocalThread来
解决。
2、facade中是否inject DataServices看你的需要,不过,如果你使用Spring来inject,那么
跨DataServices服务调用的DataServices在同一个事务中,将没法做到。(至少目前,
我没有想到办法。)
修订记录: |