在这次项目开发实践中，我又一次尝试用Python脚本生成C#代码，其效果让我很满意 -- 提高了代码质量，可维护性和工作效率；同时降低了出错率。

看来事情在向好的方面发展。那么促成的因素是什么？我思考了一下，可能有以下2点：

1. 在用脚本生成代码方面积累的实践技术经验
2. 在运用第1点时，让我感受到了“数据建模”和“框架设计”

回忆这次设计过程，我首先识别了下面几个部分的数据：

1. 前端展示数据
2. 业务层数据
3. 数据层数据

通过一个Excel表格，将这三层数据定义出来，然后再用脚本生成代码。但是，由于这次的业务不复杂，因此，这三层数据都定义在了一个表格中。

当完成这部分工作之后，再往回看，这个过程不就是数据建模过程吗？

当表格定义完成后，再根据表格中的定义去写Python脚本，生成前端展示层，业务层和数据层的代码。而这些生成的代码，实际上都是代表特定功能的函数代码。

这里我想到了常见MVC框架，MVC框架不也是提供了一套完整的函数实现了访问请求和内容展现吗？实际上再扩大一些，框架做的都是这个事情。

现在，似乎可以得出这个结论：

数据模型 + 框架 = 可运行的系统。

这是一个很简单的等式，展现在我们眼前的景象是我们的日常开发工作就是把数据模型建好，然后把它们塞进框架中，这样我们就可以休息了。如果你真的相信这幅景象，那说明你被暂时洗脑了。

在我们的项目中，处处都是包含有成百上千行代码的cs文件，随便打开一个存储过程就有上千行的代码，它们是bug的温床，像噩梦一般时时困扰着我们。那这些代码是什么代码？

我认为，这些代码可以被分为下面两种：

1. 业务逻辑转换的代码
2. 让框架识别数据的代码

业务逻辑转换的代码，最突出的如以下代码

条件分支

if (businessType == 'Rental')
{
    ....
}
else if(businessType == 'Lease')
{
    ....
}
else
{
    ....
}

适配转换

public string FirstName{get;set;}

public string LastName{get;set;}

public string FullName{return FirstName + " " + LastName;}

上面的代码仅仅反应的业务逻辑。几乎不涉及任何技术。

让框架识别数据的代码，典型的如下的数据库访问

using(var cmd = con.CreateCommand()){
    cmd.CommandText = "sp_XXX";
    cmd.Parameters.Add(....);
    using(var reader = cmd.ExecuteReader())
    {
        ...
    }
}

上面的代码告诉ADO.net框架，我们要调用存储过程，并为其设置参数。

但是通常的情况下，我们很容易会将上面两种代码混合起来，并很容易认为这是理所当然的。

但是，很快，有人意识到了问题，开发出来了ORM框架，比如NHibernate，Entity Framework等等。这样，框架识别数据的代码变成了下面这样。

[Table("T_Customer")]
public class Customer{
    [Column("FIRSTNAME")]
    public string FirstName{get;set;}
    ...
}

 这是一个开始，但不是结束。我们对框架的设计还可以根据业务需要，将框架的设计从技术层面向业务层面推进。

因此现在可以再次回到上面那个等式

　　数据模型 + 框架 = 可运行的系统

 我们可以从这个等式出发，分别从数据模型和框架的角度去设计程序。