最近在公司内部做技术交流的时候，说起技能提升的问题，调研大家想要培训什么，结果大出我意料，很多人想要培训：面向对象编码。于是我抛出一个问题：你觉得我们现在的代码是面向对象的吗？有人回答：是，有人回答否。我对这个问题的回答是：语法上，是了，但是架构上或者思想上，不是。我们现在的大部分代码，如果要死扣一个名词的话，那就是：事务脚本。

1：最开始的事务脚本

在 Martin Fowler 的书中，存在一个典型的 应用场景，即“收入确认”（Revenue Recognition）。该“收入确认”的描述：

一家软件公司有3种产品，其售价策略分别为，第一种：交全款才能卖给你；第二种，付三分之一，就给你，60天后，再给1/3，90天后给完全部；第三种，付1/3，就给你，30天后给1/3，60天后给完。

但是，关于这个描述，我打算多啰嗦几句，而且个人觉的这个啰嗦非常之紧要，因为它影响到了我们的设计。以下是啰嗦的部分：

“收入确认”，在概念上，确实是产品的入账策略，实际上，Martin 的代码，也是这么去实现的，不同的产品有不同的入账策略。不过，数据库实现，RevenueRecognition 这个表记录的是“产品的某个合同根据产品类型所计算出来的：应该执行的入账日及金额”，即策略是跟着合同走的，而不是跟着产品走的。这很有意思，如果你精读此部分，这种矛盾就会一直纠结在你心头。同时，我们又不得不时刻提醒自己存在的这个需求。

现在，关于这个场景，如果我们理解了 产品 合同 RevenueRecognition 之间的关系，我们就很能理解了数据库是被设计成这样的：

其概念模型为如下：

好了，现在我们来看看什么是事务脚本，对的，就用代码来说话。在原文中， Martin 举了两个例子，但是精读之后，我打算将其颠个倒，把原文中的示例2讲在前头。因为示例2，很好的表达了什么才是作者或者译者眼中的“收入确认”，以及我眼中的“收入策略”。

第一个要实现的功能，即第一个事务脚本描述如下：

根据合同 ID，找到该合同，并根据合同类型得到应该在哪天收入多少钱，并插入数据库。

从该描述中，我们知道，这个脚本最应该发生在签订合同时。因为合同一旦签订，就应该记录什么时候应该收到客户端多少钱。代码如下：

class RecognitionService
{
    dynamic dal = null;
   
    // 计算哪天该入账多少并插入
    public void CalculateRevenueRecognitions(long contactNumber)
    {
        DataSet contractDs = dal.FindContract(contactNumber);
        double totalRevenue = (double)contractDs.Tables[0].Rows[0]["ID"];
        DateTime dateSigned = (DateTime)contractDs.Tables[0].Rows[0]["DateSigned"];
        string type = (string)contractDs.Tables[0].Rows[0]["Type"];
        if(type == "S")    // 电子表格类
        {
            // the sql "INSERT INTO REVENUECONGNITIONS (CONTRACT,AMOUNT,RECOGNIZEDON) VALUES (?,?,?)"
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned);
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(60));
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(90));
        }else if(type == "W")    // 文字处理
        {   
            dal.InsertRecognition(contactNumber, totalRevenue, dateSigned);
        }else if(type == "D")    // 数据库
        {   
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned);
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(30));
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(60));
        }
    }   
}

第二个需求是：计算某合同在某个日期前的应该有的入账。

class RecognitionService
{
    dynamic dal = null;
        
    // 得到哪天前入账了多少
    public double RecognizedRevenue(long contractNumber, DateTime asOf)
    {
        // the sql "SELECT AMOUNT FROM REVENUECONGNITIONS WHERE CONTRACT=? AND RECOGNIZEDON <=?";
        DataSet ds = dal.FindRecognitionsFor(contractNumber, asOf);
        double r = 0.0;
        foreach(DataRow dr in ds.Tables[0].Rows)
        {
            r += (double)dr["AMOUNT"];
        }
       
        return r;
    }
}

从上面的代码，我们可以看出什么才是 事务脚本：

1：采用面向过程的方式组织业务逻辑；
2：没有或尽量少的实体类；
3：一个方法一件事情，故有大量业务类或方法；
4：能与行数据入口和表数据入口很好协作；

2：事务脚本之变体

也许上面的代码多多少少让大家嗤之以鼻，认为现在很少会这样来写代码了。那么，我们来看看下面这段代码：

class RecognitionBll
{
    dynamic dal = null;
   
    // 计算哪天该入账多少并插入
    public void CalculateRevenueRecognitions(long contactNumber)
    {
        List<Contact> contracts = dal.FindContract(contactNumber);
        double totalRevenue = (double)contracts[0].Id;
        DateTime dateSigned = (DateTime)contracts[0].DateSigned;
        string type = (string)dal.FindContractType(contactNumber);
        // 上面这行代码你还可能会写成
        // string type = (string)dal.contracts[0].ProductType;
        // 或者
        // string type = (string)dal.contracts[0].Product.Type;
        if(type == "S")    // 电子表格类
        {
            // the sql "INSERT INTO REVENUECONGNITIONS (CONTRACT,AMOUNT,RECOGNIZEDON) VALUES (?,?,?)"
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned);
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(60));
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(90));
        }else if(type == "W")    // 文字处理
        {   
            dal.InsertRecognition(contactNumber, totalRevenue, dateSigned);
        }else if(type == "D")    // 数据库
        {   
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned);
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(30));
            dal.InsertRecognition(contactNumber, totalRevenue / 3, dateSigned.AddDays(60));
        }
    }
   
    // 得到哪天前入账了多少
    public double RecognizedRevenue(long contractNumber, DateTime asOf)
    {
        // the sql "SELECT AMOUNT FROM REVENUECONGNITIONS WHERE CONTRACT=? AND RECOGNIZEDON <=?";
        List<RevenueRecognition> revenueRecognitions = dal.FindRecognitionsFor(contractNumber, asOf);
        double r = 0.0;
        foreach(RevenueRecognition rr in revenueRecognitions)
        {
            r += rr.Amount;
        }
       
        return r;
    }
}

public class Product
{
    public long Id;
    public string Name;
    public string Type;
}

public class Contact
{
    public long Id;
    public long ProductId;
    public string ProductType;
    public Product Product;
    public double Revenue;
    public DateTime DateSigned;
}

public class RevenueRecognition
{
    public long ContactId;
    public double Amount;
    public double RevenuedOn;
}

在这个事务脚本的变种中，我们看到了所有人写过代码的影子：

1：有了实体类了，所以看上去貌似是面向对象编码了；

2：看到了 “三层架构” 了，即：实体层、DAL层、业务逻辑层等；

但是，它仍旧是 事务脚本 的！唯一不同的是，它光鲜的把 DataSet 变成了 List<Model> 了！

3：什么是面向对象的？

那么，什么是面向对象的编码，面向对象的一个很重要的点就是：“把事情交给最适合的类去做”，并且“你得在一个个业务类之间跳转，才能找出他们如何交互”。这确实是个不那么简单的话题，而本文的主旨也仅在于指出，如果我们的代码中还没有 工作单元 映射 缓存 延迟加载 等等概念，即便我们编码再熟练，也仅仅是在熟练的 面向过程编码。