Transaction Script 、 Doamin Model、Logic SQL

                                  Transaction Script 、 Doamin Model、Logic SQL

 

                                  TomHornson#(at)#hotmail.com

      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在同一个事务中，将没法做到。(至少目前，
           我没有想到办法。)

修订记录： 第一次：12/6/2004