profile for Macon_Cao at Stack Overflow, Q&A for professional and enthusiast programmers
随笔-124  评论-193  文章-0 

数据建模与框架设计的暂时总结

在这次项目开发实践中,我又一次尝试用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;}
    ...
}

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

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

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

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

 

posted on 2015-12-07 07:32 CQ-Coder 阅读(...) 评论(...) 编辑 收藏