在这次项目开发实践中，我又一次尝试用Python脚本生成C#代码，其效果让我很满意 -- 提高了代码质量，可维护性和工作效率；同时降低了出错率。
看来事情在向好的方面发展。那么促成的因素是什么？我思考了一下，可能有以下2点：
- 在用脚本生成代码方面积累的实践技术经验
- 在运用第1点时，让我感受到了“数据建模”和“框架设计”
回忆这次设计过程，我首先识别了下面几个部分的数据：
- 前端展示数据
- 业务层数据
- 数据层数据
通过一个Excel表格，将这三层数据定义出来，然后再用脚本生成代码。但是，由于这次的业务不复杂，因此，这三层数据都定义在了一个表格中。
当完成这部分工作之后，再往回看，这个过程不就是数据建模过程吗？
当表格定义完成后，再根据表格中的定义去写Python脚本，生成前端展示层，业务层和数据层的代码。而这些生成的代码，实际上都是代表特定功能的函数代码。
这里我想到了常见MVC框架，MVC框架不也是提供了一套完整的函数实现了访问请求和内容展现吗？实际上再扩大一些，框架做的都是这个事情。
现在，似乎可以得出这个结论：
数据模型 + 框架 = 可运行的系统。
这是一个很简单的等式，展现在我们眼前的景象是我们的日常开发工作就是把数据模型建好，然后把它们塞进框架中，这样我们就可以休息了。如果你真的相信这幅景象，那说明你被暂时洗脑了。
在我们的项目中，处处都是包含有成百上千行代码的cs文件，随便打开一个存储过程就有上千行的代码，它们是bug的温床，像噩梦一般时时困扰着我们。那这些代码是什么代码？
我认为，这些代码可以被分为下面两种：
- 业务逻辑转换的代码
- 让框架识别数据的代码
业务逻辑转换的代码，最突出的如以下代码
条件分支
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;} ... }
这是一个开始，但不是结束。我们对框架的设计还可以根据业务需要，将框架的设计从技术层面向业务层面推进。
因此现在可以再次回到上面那个等式
数据模型 + 框架 = 可运行的系统
我们可以从这个等式出发，分别从数据模型和框架的角度去设计程序。