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

引言

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

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

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

以下是幾點(diǎn)說明：

• 本文中，我有時(shí)候會(huì)說到“用戶界面層”，有時(shí)候會(huì)說到“表現(xiàn)層”，這兩個(gè)在本系列文章中是一回事。
• 閱讀本文前推薦閱讀我的另一篇文章 數(shù)據(jù)庫對象命名參考。
• 本系列文章的 Source Code 和 T-SQL 腳本將會(huì)在所有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ī)則(比如本例中每天的開銷不能為負(fù)數(shù))和業(yè)務(wù)對象)、以及數(shù)據(jù)訪問層(對數(shù)據(jù)庫進(jìn)行查詢和操作)，從代碼的角度來看，是分開的。

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

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

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

為了給大家一個(gè)更生動(dòng)的認(rèn)識，我用 Visio畫了個(gè)圖給大家看看：

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

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

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

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

個(gè)人理財(cái)Web程序介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

這就是上面提到過的“初學(xué)者訪問層”，將ADO.NET 代碼揉到CodeBehind的事件處理中去，這種方法幾乎沒有可維護(hù)性，對數(shù)據(jù)庫的任何改動(dòng)，比如增減一個(gè)字段，或者給某個(gè)存儲(chǔ)過程重新命名，都要導(dǎo)致修改大量的相關(guān)文件。另外，這種方法還有一個(gè)致命的缺點(diǎn)：無法實(shí)現(xiàn)代碼重用。其實(shí)這種方法不應(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控件”中詳細(xì)討論了 SqlDataSource 的種種特性，其中，比較重要的就是使用代碼后置的方法動(dòng)態(tài)的創(chuàng)建和配置 SqlDataSource 控件，并提供對頁面數(shù)據(jù)控件的綁定。這就提供了一種新的實(shí)現(xiàn)數(shù)據(jù)訪問層的思路 – 使用SqlDataSource 作為數(shù)據(jù)訪問層。

在這里不得不說明一點(diǎn)，ObjectDataSource 其實(shí)就是完全自定義的 SqlDataSource 控件，想想看你是如何使用 SqlDataSource 的？我想你一定在前端頁面通過拖拽控件的方式使用過SqlDataSource ，也一定注意到 SqlDataSource 的幾個(gè)重要屬性，SelectCommand、UpdateCommand 等，在使用 SqlDataSource 時(shí)，向?qū)ё詣?dòng)為你生成 Sql 語句(也可以自己寫)，然后顯示在.aspx文件中，如果你實(shí)現(xiàn)了 UpdateCommand、InsertCommand (SelectCommand是必須要實(shí)現(xiàn)的)，SqlDataSource 也就具有了相應(yīng)的功能。而 ObjectDataSource 是如何運(yùn)作的呢？它要求你自己寫全部的Code以實(shí)現(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頁面中，而且代碼臃腫不堪。盡管你可以使用代碼后置的方式去實(shí)現(xiàn)這些，但代價(jià)就是降低了開發(fā)效率，因?yàn)槭謱懕饶阃蟿?dòng)控件、使用向?qū)б锰唷?/p>

使用TableAdapter和 強(qiáng)類型的DataSet

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

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

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

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

相比之下，強(qiáng)類型DataSet是從這些類派生出來的。

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

那又為什么稱它們?yōu)椤皬?qiáng)類型”DataSet呢？因?yàn)樵趶?qiáng)類型DataSet中，是使用一種類型安全的方式來使用其中的每一個(gè)對象，光是說術(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)，我們在獲取一個(gè)字段的值時(shí)，需要使用DataSet的索引器，逐步獲得DataSet層次結(jié)構(gòu)的每一個(gè)片段，直到最后抵達(dá)行級，在這個(gè)過程中，任何的拼寫錯(cuò)誤都會(huì)導(dǎo)致拋出異常。

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

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

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

daDailyCost.Fill(dataSet,”ShowCost”);

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

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

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

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

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

我能想到這種方式，當(dāng)然很多人也能想到，所以，網(wǎng)上的開源站點(diǎn)及一些個(gè)人站點(diǎn)已經(jīng)提供了這個(gè)封裝好的類的下載，其中大多是靜態(tài)類，因?yàn)轭愖髡咚礁叩筒痪?，所以類的質(zhì)量也是良莠不齊。另外，幾乎所有這個(gè)類都約定俗成般起了同一個(gè)名字，叫做 -- SqlHelper 。

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

使用新一代的 LINQ

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

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

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

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

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

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

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

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

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

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

需求分析

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

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

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

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

總結(jié)

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

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

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

最后，我們對這個(gè)“個(gè)人理財(cái)程序”做了一下簡單需求分析。

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