Asp.Net 三層式Web應(yīng)用程序開發(fā) - Part.1

引言

本文是 “使用Asp.Net構(gòu)建三層式Web 應(yīng)用程序” 系列文章的第一部分。在這一系列文章中，我將系統(tǒng)的講述如何使用 Asp.Net 設(shè)計、構(gòu)建、實現(xiàn)三層式Web應(yīng)用程序。本文的讀者應(yīng)該是有一定Asp.Net基礎(chǔ)的開發(fā)者，同時要求對數(shù)據(jù)庫、C#、Ajax、Web Service也有一定的了解。這系列文章使用我目前正在使用的一個“個人理財程序”作為范例講解，這個程序非常小，只有三個表，但麻雀雖小五臟俱全，我主要想利用它為大家闡明一些概念，可能功能并不完備，但對于教程所討論的主題沒有影響，感興趣的話可以自行擴展它。

古人云：條條大道通羅馬。所以，我這里講述的，只是我個人的三層式Web應(yīng)用程序?qū)崿F(xiàn)，并不是說只有這一種實現(xiàn)方法，也不能說明這種實現(xiàn)方法是最好的。

• 這系列文章計劃分為五個部分，其中每個部分的內(nèi)容如下：
• Part 1. 講解三層式Web應(yīng)用程序的概念，數(shù)據(jù)訪問層的實現(xiàn)方式，“個人理財程序”的程序介紹以及 需求分析。
• Part 2. 講解 系統(tǒng)的概要、詳細設(shè)計，數(shù)據(jù)庫的實現(xiàn)，業(yè)務(wù)層對象類的實現(xiàn)步驟和方法。
• Part 3. 講解 數(shù)據(jù)訪問層 和 業(yè)務(wù)邏輯層 的代碼實現(xiàn)。
• Part 4. 講解 用戶界面層 的實現(xiàn)，以及如何使用 ObjectDataSource 調(diào)用業(yè)務(wù)邏輯層中的對象和方法。
• Part 5. 講解如何為 Part 4. 中實現(xiàn)的部分加上 Web Service 和 Asp.Net Ajax。

以下是幾點說明：

• 本文中，我有時候會說到“用戶界面層”，有時候會說到“表現(xiàn)層”，這兩個在本系列文章中是一回事。
• 閱讀本文前推薦閱讀我的另一篇文章 數(shù)據(jù)庫對象命名參考。
• 本系列文章的 Source Code 和 T-SQL 腳本將會在所有Part全部發(fā)布后提供下載。

本系列文章使用的開發(fā)環(huán)境是 VS 2005 + SQL Server 2000，操作系統(tǒng)是 Windows Server 2003 Enterprise Edition。T-SQL 代碼我只在 SQL Server 2000 下測試了，如果在 SQL Server 2005下不能通過，請反饋給我。

三層式開發(fā)介紹

分層式開發(fā)是一種開發(fā)模式，在這種模式中，用戶界面層(用戶所看到和與其交互的那部分)、業(yè)務(wù)邏輯層(業(yè)務(wù)規(guī)則(比如本例中每天的開銷不能為負數(shù))和業(yè)務(wù)對象)、以及數(shù)據(jù)訪問層(對數(shù)據(jù)庫進行查詢和操作)，從代碼的角度來看，是分開的。

這種模式具有很多的優(yōu)點：

1. 你的代碼非常的“干凈”。可以試想一下，如果你把提交表單的ADO.NET數(shù)據(jù)庫操作全都寫到頁面的 CodeBehind文件中，會是多么的凌亂？
2. 更好的可維護性，程序員之間的分工明確，各層之間只需要知道調(diào)用接口就可以了，而不需要知道是如何實現(xiàn)的。
3. 更好的可移植性，可以聯(lián)想一下 微軟的數(shù)據(jù)訪問技術(shù) 從 ODBC 到 OLEDB 到 ADO再到 ADO.Net 1.1 一直到如今的 ADO.NET 2.0，幾乎每三年就會有一次變革，采用分層式開發(fā)，可以在系統(tǒng)升級的時候更少的受到影響。
4. 更好的對分布式應(yīng)用程序的支持。

NOTE：提到分布式應(yīng)用程序時常會遇到兩個英文單詞: Tier 和 Layer ，這兩個單詞的意思翻譯過來都是 “層”，但是有什么區(qū)別呢？老外通常提到Tier 的時候，指的是物理上分層；提到 Layer 的時候，常指的是邏輯上分層。物理上分層說的簡單點，就是用戶界面層在一臺服務(wù)器，業(yè)務(wù)邏輯層在一臺服務(wù)器，數(shù)據(jù)訪問層又在另一臺服務(wù)器(也可以表現(xiàn)層和業(yè)務(wù)層在同一臺服務(wù)器，數(shù)據(jù)訪問層在一臺服務(wù)器，總之三個層不在一臺服務(wù)器)。而邏輯上分層我現(xiàn)在正在講述，很容易就想得通：如果物理上分層了，邏輯上也一定分層了；但如果邏輯上分層了，物理上不一定是分層的，可以部署在同一臺服務(wù)器上，比如我的這個“個人理財程序”。

為了給大家一個更生動的認識，我用 Visio畫了個圖給大家看看：

圖1. 三層式程序結(jié)構(gòu)圖

這張圖描述了這個應(yīng)用程序中數(shù)據(jù)流動的大致方向。

請大家從用戶和左邊的箭頭看起：

1. 用戶瀏覽網(wǎng)頁時，首先面對的是用戶界面層或者說表現(xiàn)層，如果用戶進行一個對數(shù)據(jù)庫查詢的操作，請求首先會發(fā)送到業(yè)務(wù)邏輯層。
2. 業(yè)務(wù)邏輯層對用戶提交的數(shù)據(jù)進行校驗，如果有問題，將拒絕用戶請求并給出錯誤提示；如果沒有問題，業(yè)務(wù)邏輯層將用戶請求遞交給數(shù)據(jù)訪問層。
3. +數(shù)據(jù)訪問層充當業(yè)務(wù)邏輯層與數(shù)據(jù)庫之間的一個橋梁，把請求遞交給數(shù)據(jù)庫，不應(yīng)該在這一層再去做一些數(shù)據(jù)校驗的工作，來自業(yè)務(wù)邏輯層的數(shù)據(jù)應(yīng)該被認為是無誤的，這層的代碼相對于業(yè)務(wù)邏輯層來說是很清爽的。
4. 數(shù)據(jù)庫進行查詢后將結(jié)果集返回給數(shù)據(jù)訪問層，接著再返回給業(yè)務(wù)邏輯層，最后呈現(xiàn)給用戶。這是一個典型的冒泡過程。在這個過程中，任何沒有Catch的異常都會拋出，冒泡到用戶界面層，這也就是為什么你訪問aspx的頁面，看到的卻是來自數(shù)據(jù)庫的“Can’t connect to database”的原因。

個人理財Web程序介紹

我是一個不會理財?shù)娜?，在過去兩年零一個月的時間，一毛錢都沒有攢下，一個人的時候，我時常思索為什么我的錢總是來也匆匆去也匆匆，在現(xiàn)在老婆房子女朋友都沒有的三無情況下，這樣繼續(xù)下去將會給我的人生帶來深遠的影響。

沉默了許久之后，我終于覺悟了... ..我想做的第一件事，就是解決長期困擾我的頭號問題 -– 我的錢都跑哪兒去了？于是，這個個人理財程序便應(yīng)運而生了。

其實如果只是我一個人使用的話，只需要一個表，就足以構(gòu)建這個應(yīng)用程序了。我給這個表起名叫：DailyCost，用來記錄每天的開銷/收入項目，表的字段分別是：

CostId：自動編號，主鍵。
Type：0，表示開銷；1，表示收入
Purpost：開銷用途/收入來源
Amount：數(shù)額
CostDate：開銷日期

但是，這么好的程序(NOTE：和我一樣不會理財?shù)娜藨?yīng)該也不少吧?)，只有我一個人用簡直太浪費了，讓我們來對它進行了一下擴展，讓更多的人可以使用吧。這樣，就很有必要再加一個 User 表，記錄使用此系統(tǒng)的用戶，這個表應(yīng)該包含如下字段：

UserId：自動編號，主鍵。
Name：用戶的名字
BirthDay：生日
Phone：用戶的電話

此時，應(yīng)該修改DailyCost表，以實現(xiàn)參照完整性(NOTE：也叫外鍵約束)。給DailyCost表再加一個字段：FKUserId，此條消費記錄是屬于哪位用戶的。

在現(xiàn)在這個苦力都拿手機的時代，人們的Phone是會有很多的，比如手機一個，辦公室一個，家里一個。所以，我們應(yīng)該把Phone字段抽象出來，形成與User表的一對多關(guān)系。

建立 Phone 表，字段如下：
PhoneId：自動編號，主鍵。
Number：號碼
Type：0，手機；1，家里；2，公司；3，其他
FKUserId：外鍵，此Phone是哪位用戶的

OK，這部分就先介紹到這里，在后面的 概要/詳細設(shè)計中會再次講解。

NOTE：概要設(shè)計和詳細設(shè)計我合并了，因為這個應(yīng)用程序比較小，合并到一起我想大家已經(jīng)可以看明白，分開講解可能會顯得文章過于繁瑣。

實現(xiàn)數(shù)據(jù)訪問層的不同方式

與用戶界面揉在一起的數(shù)據(jù)訪問層

這就是上面提到過的“初學者訪問層”，將ADO.NET 代碼揉到CodeBehind的事件處理中去，這種方法幾乎沒有可維護性，對數(shù)據(jù)庫的任何改動，比如增減一個字段，或者給某個存儲過程重新命名，都要導致修改大量的相關(guān)文件。另外，這種方法還有一個致命的缺點：無法實現(xiàn)代碼重用。其實這種方法不應(yīng)該稱作“層”，但是為了文章的完備性，我還是在這里把它提出來。

用這種方式寫的代碼通常都是這樣的：

protected void Page_Load(object sender, EventArgs e)
{  
  if (!Page.IsPostBack)
  {
    string sqlText = @"SELECT Purpose, Amount,
        Type FROM DailyCost WHERE CostId = 1";

    using (SqlConnection conn =
        new SqlConnection(ConfigurationManager.ConnectionStrings["JimmyCost"]
        .ConnectionString))
    {
      using (SqlCommand myCommand = new SqlCommand(sqlText, conn))
      {
        conn.Open();
        using (SqlDataReader myReader = myCommand.ExecuteReader())
        {
          if (myReader.Read())
          {
            txtPurpose.Text = myReader.GetString(0);
            txtAmount.Text = myReader.GetString(1);
         txtType.Text = myReader.GetString(2);
         }
          myReader.Close();
        }
        conn.Close();
      }
    }
  }
}

protected void btnSave_Click(object sender, EventArgs e)
{
  string sqlText = @"UPDATE DailyCost SET Purpose='{0}',
  Amount='{1}', Type ='{2}' WHERE Id = 1";
  using (SqlConnection conn =
        new SqlConnection(ConfigurationManager.ConnectionStrings["JimmyCost"]
            .ConnectionString))
  {
    string sql = String.Format(sqlText,
           txtPurpose.Text, txtAmount.Text, txtType.Text);
    SqlCommand cmd = new SqlCommand(sql, conn);
    conn.Open();
    cmd.ExecuteNonQuery();
    conn.Close();
  }
}

使用SqlDataSource 作為數(shù)據(jù)訪問層

在這里我推薦給大家一本好書，由電子工業(yè)出版社出版的，奚江華寫作的《圣殿祭祀的ASP.NET 2.0開發(fā)詳解》。在這本書中，作者在第11章 — “新一代數(shù)據(jù)訪問方式DataSource控件”中詳細討論了 SqlDataSource 的種種特性，其中，比較重要的就是使用代碼后置的方法動態(tài)的創(chuàng)建和配置 SqlDataSource 控件，并提供對頁面數(shù)據(jù)控件的綁定。這就提供了一種新的實現(xiàn)數(shù)據(jù)訪問層的思路 – 使用SqlDataSource 作為數(shù)據(jù)訪問層。

在這里不得不說明一點，ObjectDataSource 其實就是完全自定義的 SqlDataSource 控件，想想看你是如何使用 SqlDataSource 的？我想你一定在前端頁面通過拖拽控件的方式使用過SqlDataSource ，也一定注意到 SqlDataSource 的幾個重要屬性，SelectCommand、UpdateCommand 等，在使用 SqlDataSource 時，向?qū)ё詣訛槟闵?Sql 語句(也可以自己寫)，然后顯示在.aspx文件中，如果你實現(xiàn)了 UpdateCommand、InsertCommand (SelectCommand是必須要實現(xiàn)的)，SqlDataSource 也就具有了相應(yīng)的功能。而 ObjectDataSource 是如何運作的呢？它要求你自己寫全部的Code以實現(xiàn) Command，區(qū)別就是，你可以把這些Command全部封裝到類或者說業(yè)務(wù)邏輯層中去。

好了，說了這么多，讓我們看看使用SqlDataSource作為數(shù)據(jù)訪問層的典型頁面吧。

<asp:SqlDataSource  
ID="SqlDataSource1" runat="server"  
ConnectionString="<%$ ConnectionStrings:JimmyConn %>"  
DeleteCommand="DELETE FROM [DailyCost] WHERE [CostId] = @original_Id"
InsertCommand="INSERT INTO [DailyCost] ([Purpose], [Type],
    [Amount], [CostDate]) VALUES (@Purpose,
    @Type, @Amount, @CostDate)"
SelectCommand="SELECT * FROM [DailyCost]"
UpdateCommand="UPDATE [DailyCost] SET [Purpose] = @Purpose,
    [Type] = @Type, [Amount] = @Amount,
    [CostDate] = @CostDate WHERE [CostId] = @original_Id"  OldValuesParameterFormatString="original_{0}"
>
<DeleteParameters>
    <asp:Parameter Name="original_Id" Type="Int32" />
</DeleteParameters>
<UpdateParameters>
    <asp:Parameter Name="Purpose" Type="String" />
    <asp:Parameter Name="Type" Type="Bool" />
    <asp:Parameter Name="Amount" Type="Decimal" />
    <asp:Parameter Name="CostDate" Type="DateTime" />
    <asp:Parameter Name="original_Id" Type="Int32" />
</UpdateParameters>
<InsertParameters>
    <asp:Parameter Name="Purpose" Type="String" />
    <asp:Parameter Name="Type" Type=" Bool " />
    <asp:Parameter Name="Amount" Type="Decimal" />
    <asp:Parameter Name="CostDate" Type="DateTime" />
</InsertParameters></asp:SqlDataSource>

很明顯就可以看到，不僅關(guān)于數(shù)據(jù)訪問的Sql 語句直接寫到了 .aspx頁面中，而且代碼臃腫不堪。盡管你可以使用代碼后置的方式去實現(xiàn)這些，但代價就是降低了開發(fā)效率，因為手寫比你拖動控件、使用向?qū)б锰唷?/p>

使用TableAdapter和 強類型的DataSet

VS 2005 提供強類型的 DataSet ，可以通過 VS2005向?qū)?來創(chuàng)建，熟練的話，是創(chuàng)建數(shù)據(jù)訪問層最快的一種方式，微軟官方站點 www. ，有一個關(guān)于數(shù)據(jù)訪問的系列教程，目前出到快 70 章了(NOTE：我大概算了一下，可以出本900頁的書了)，仍在不斷更新中，這個教程使用的就是這種模型。

這里我僅簡要說明一下什么是強類型的DataSet，和普通的DataSet有什么區(qū)別，至于如何創(chuàng)建強類型的DataSet，需要一個獨立的章節(jié)來介紹，我以后再發(fā)文章補上。

強類型DataSet(Typed DataSet)并不是 .NET 框架直接提供的一系列類，而是從DataSet類繼承而來的，下圖先給大家演示了傳統(tǒng)的DataSet和它包含的各個元素之間的關(guān)系。

這里黑色的菱形箭頭表示的是合成的方向，下面這幅圖中，空心的三角，表示的是泛化的方向。合成，說通俗一點，或者用數(shù)據(jù)庫的術(shù)語來說(NOTE: 用在這里并不恰當，純粹為了解說方便)，就是多對一關(guān)系，拿這幅圖來說，就是好多個 DataRow 合成了DataTable，同時DataTable 還可以有DataColumn，Constraint和DataRelation；同時，很多個DataColumn又合成了Constraint和DataRelation。最后，好多個DataTable和 DataRelation合成了DataSet。

相比之下，強類型DataSet是從這些類派生出來的。

這幅圖該如何解讀我就不詳細解釋了，留給大家一點思考的空間。

那又為什么稱它們?yōu)椤皬婎愋汀盌ataSet呢？因為在強類型DataSet中，是使用一種類型安全的方式來使用其中的每一個對象，光是說術(shù)語很難懂什么叫類型安全的方式，讓我們看下面的代碼范例吧。

我們先看一段使用傳統(tǒng)DataSet的代碼。

// 前面省略部分代碼
SqlDataAdapter daDailyCost = new SqlDataAdapter(“Select * From DailyCost”, conn);

DataSet dataSet = new dataSet;

daDailyCost.Fill(dataSet, “ShowCost”);

Console.WriteLine(dataSet.Tables[“ShowCost”].Rows[0][“CostId”].ToString());

可以發(fā)現(xiàn)，我們在獲取一個字段的值時，需要使用DataSet的索引器，逐步獲得DataSet層次結(jié)構(gòu)的每一個片段，直到最后抵達行級，在這個過程中，任何的拼寫錯誤都會導致拋出異常。

現(xiàn)在再看看 強類型DataSet是如何運作的。

//前面省略部分代碼
SqlDataAdapter daDailyCost = new SqlDataAdapter(“Select * From DailyCost”,conn);

//DailyCostTD 是實現(xiàn)了的強類型dataSet，至于如何實現(xiàn)，我以后會另寫文章
DailyCostTD  dataSet = new DailyCostTD();

daDailyCost.Fill(dataSet,”ShowCost”);

Console.WriteLine(dataSet.Customer[0].Purpose);

在這里，大家似乎覺得這兩個沒太大區(qū)別，無非就是在 Console.WriteLine的時候少打幾個字而已，其實不然，在你用強類型DataSet的時候，VS2005會提供智能提示(NOTE：就是打個i，int就顯示出來了，你只要拍下空格就好了)，這樣，就大大降低了編寫時發(fā)生手誤的機會。

既然強類型DataSet這么好用，為什么不干脆使用它作為數(shù)據(jù)訪問層呢？前面我也提到過，使用類型化DataSet是創(chuàng)建數(shù)據(jù)訪問層最快的方式，你只需要建立一個.xsd數(shù)據(jù)集文件，然后拖拽控件，再使用向?qū)гO(shè)置一下基本就可以Run了。但是，代價就是幾乎沒有擴展性，因為代碼都是自動生成的，你很難去修改它(NOTE：其實還是有辦法可以改的，你可以通過寫部分類的方式去擴展它)，另外，重用性也比較差。

使用封裝的ADO.NET數(shù)據(jù)訪問層類

與“初學者訪問層”相同的地方是：這種方式也是采用的全手寫 ADO.NET 代碼來實現(xiàn)的；不同的是，將所有對于數(shù)據(jù)庫的操作封裝到了一個類中，這個類是高度整合的，你甚至可以不加改動將它用在其它的項目中。

我能想到這種方式，當然很多人也能想到，所以，網(wǎng)上的開源站點及一些個人站點已經(jīng)提供了這個封裝好的類的下載，其中大多是靜態(tài)類，因為類作者水平高低不均，所以類的質(zhì)量也是良莠不齊。另外，幾乎所有這個類都約定俗成般起了同一個名字，叫做 -- SqlHelper 。

這里有一個比較不錯的老外寫的 SqlHelper類，感興趣的可以參考一下。

使用新一代的 LINQ

還有一種方式就是使用LINQ，很多人可能還是第一次聽說這個名詞，那么我就稍微的介紹一下：

簡單來說，Linq 就是幫助編譯器理解和實現(xiàn)內(nèi)存中保存的對象集合的一組特性。這樣說可能比較繞口，Linq中有一個組件，稱做Linq To Sql，它提供了一個在運行時將關(guān)系數(shù)據(jù)庫數(shù)據(jù)處理成對象的底層機制，并且還不喪失關(guān)系數(shù)據(jù)庫的查詢功能。它通過將面向語的查詢翻譯成數(shù)據(jù)庫可執(zhí)行的查詢語句，再將語句提交給數(shù)據(jù)庫，然后把數(shù)據(jù)庫返回的結(jié)果集映射成開發(fā)者定義的對象來完成。

上面的說法如果沒有實際動手體會一下，或者看一些范例，相信不是太好理解。在我的個人博客 jimmyzhang.cnblogs.com 上已經(jīng)陸續(xù)發(fā)布了來自微軟開發(fā)團隊的ScottGu的“Linq To Sql介紹”系列文章，有興趣的朋友可以去看一看。

不使用Linq的主要原因是它現(xiàn)在還處于Beta版本，正式發(fā)布時可能還會有改進。另外，目前的主機大多都只支持到.Net Framework 2.0，所以使用LINQ尚為時過早。

使用自定義的業(yè)務(wù)邏輯層對象

終于，我們的主角登場了。很多情況下，業(yè)務(wù)對象只是一個由其他對象繼承的簡單的類，也可以實現(xiàn)一些接口讓它變得更好用一些。在我們的這個系統(tǒng)中，Phone對象像下面這樣：

public class Phone
{
    private int phoneid = -1;
    private string number;
    private PhoneType type;         // PhoneType是一個枚舉

    public string Number{
       get{return number;}
       set{number = value;}
    }
}    //以下代碼省略

在實踐中，通常業(yè)務(wù)對象只包含數(shù)據(jù)，而關(guān)于對象操作的方法則封裝到業(yè)務(wù)邏輯中去。

好了，數(shù)據(jù)訪問層的實現(xiàn)方法至此告一段落，下面讓我們開始進行需求分析 吧。

需求分析

做任何開發(fā)之前，需求分析都是很重要的步驟，如果需求都沒有搞好，就等于沒有回答用戶需要什么解決方案的問題，如果在需求分析不明確的情況下冒然進行開發(fā)，結(jié)果往往是苦戰(zhàn)兩個月，做出來的產(chǎn)品卻不是用戶想要的。另外，需求分析并不是一次成型的，在這個階段，由于還沒有深入到概要設(shè)計或者詳細設(shè)計中去，對系統(tǒng)的理解可能并不完整，所以會時?；剡^頭來修訂需求分析。

由于這個“個人理財程序”的用戶和開發(fā)人員都是我自己，所以需求分析可以認為只是打打字而已。

在這個Web應(yīng)用程序中，我們要實現(xiàn)的功能主要有這些：

1. 要求可以添加、編輯、刪除用戶
2. 要求可以添加、編輯、刪除用戶電話
3. 要求可以添加、編輯、刪除每日的開銷項目
4. 要求可以刪除 某日、某月 的全部開銷
5. 要求可以查看某天、某月、某年的花費報表
6. 要求可以統(tǒng)計每天、每月、每年各開銷了多少錢
7. 要求可以統(tǒng)計歷史花錢最高的日期和開銷/收益的數(shù)額
8. 要求可以統(tǒng)計歷史花錢最低的日期和開銷/收益的數(shù)額
9. 要求可以統(tǒng)計自系統(tǒng)運行以來總共開銷了多少錢
10. 要求可以統(tǒng)計自系統(tǒng)運行以來總共收益了多少錢
11. 要求可以查看某個用戶所有的聯(lián)系方式

總結(jié)

本文是使用 Asp.Net構(gòu)建三層 Web應(yīng)用程序的第一部分。

我們首先了解了什么是三層式開發(fā)模式，接著提出了一個很現(xiàn)實的需要解決的問題，并對這個問題做了一些簡單的分析。

然后，我們花了很大的篇幅，講解實現(xiàn)數(shù)據(jù)訪問層的各種方式，并簡要介紹了我們即將采用的方法。

最后，我們對這個“個人理財程序”做了一下簡單需求分析。

希望這篇文章能給你帶來幫助。