最近在公司内部做技术交流的时候，说起技能提升的问题，调研大家想要培训什么，结果大出我意料，很多人想要培训：面向对象编码。于是我抛出一个问题：你觉得我们现在的代码是面向对象的吗？有人回答：是，有人回答否。我对这个问题的回答是：语法上，是了，但是架构上或者思想上，不是。我们现在的大部分代码，如果要死扣一个名词的话，那就是：事务脚本。
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：什么是面向对象的？
那么，什么是面向对象的编码，面向对象的一个很重要的点就是：“把事情交给最适合的类去做”，并且“你得在一个个业务类之间跳转，才能找出他们如何交互”。这确实是个不那么简单的话题，而本文的主旨也仅在于指出，如果我们的代码中还没有 工作单元 映射 缓存 延迟加载 等等概念，即便我们编码再熟练，也仅仅是在熟练的 面向过程编码。
本文基于
Creative Commons Attribution 2.5 China Mainland License发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名
http://www.cnblogs.com/luminji（包含链接）。如您有任何疑问或者授权方面的协商，请给我留言。
