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

goodwangLib 2014-05-02

展開全文

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)點：

你的代碼非常的“干凈”,?？梢栽囅胍幌拢绻惆烟峤槐韱蔚腁DO.NET數(shù)據(jù)庫操作全都寫到頁面的 CodeBehind文件中,，會是多么的凌亂,？
更好的可維護性，程序員之間的分工明確,，各層之間只需要知道調(diào)用接口就可以了,，而不需要知道是如何實現(xiàn)的。
更好的可移植性,，可以聯(lián)想一下微軟的數(shù)據(jù)訪問技術(shù) 從 ODBC 到 OLEDB 到 ADO再到 ADO.Net 1.1 一直到如今的 ADO.NET 2.0,，幾乎每三年就會有一次變革，采用分層式開發(fā),，可以在系統(tǒng)升級的時候更少的受到影響,。
更好的對分布式應(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ù)流動的大致方向。

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

用戶瀏覽網(wǎng)頁時,，首先面對的是用戶界面層或者說表現(xiàn)層，如果用戶進行一個對數(shù)據(jù)庫查詢的操作,，請求首先會發(fā)送到業(yè)務(wù)邏輯層,。
業(yè)務(wù)邏輯層對用戶提交的數(shù)據(jù)進行校驗，如果有問題,，將拒絕用戶請求并給出錯誤提示,；如果沒有問題，業(yè)務(wù)邏輯層將用戶請求遞交給數(shù)據(jù)訪問層,。
+數(shù)據(jù)訪問層充當(dāng)業(yè)務(wù)邏輯層與數(shù)據(jù)庫之間的一個橋梁,，把請求遞交給數(shù)據(jù)庫，不應(yīng)該在這一層再去做一些數(shù)據(jù)校驗的工作,，來自業(yè)務(wù)邏輯層的數(shù)據(jù)應(yīng)該被認為是無誤的,，這層的代碼相對于業(yè)務(wù)邏輯層來說是很清爽的。
數(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ù)訪問層

這就是上面提到過的“初學(xué)者訪問層”，將ADO.NET 代碼揉到CodeBehind的事件處理中去,，這種方法幾乎沒有可維護性,，對數(shù)據(jù)庫的任何改動，比如增減一個字段,，或者給某個存儲過程重新命名,，都要導(dǎo)致修改大量的相關(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: 用在這里并不恰當(dāng)，純粹為了解說方便),，就是多對一關(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)的每一個片段，直到最后抵達行級,，在這個過程中,，任何的拼寫錯誤都會導(dǎo)致拋出異常。

現(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ù)訪問層類

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

我能想到這種方式,，當(dāng)然很多人也能想到，所以,，網(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)的功能主要有這些：