數據建模與框架設計的暫時總結

在此次項目開發實踐中，我又一次嘗試用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;}
    ...
}

 這是一個開始，但不是結束。咱們對框架的設計還能夠根據業務須要，將框架的設計從技術層面向業務層面推動。

所以如今能夠再次回到上面那個等式

　　數據模型 + 框架 = 可運行的系統

 咱們能夠從這個等式出發，分別從數據模型和框架的角度去設計程序。