Asp.Net三层式Web应用程序开发-Part.1

OStack程序员社区-中国程序员成长平台 › 门户 › 编程› ASP.NET›ASP.NET编程经验

原作者: [db:作者] 来自: [db:来源] 收藏邀请

引言

本文是 “使用Asp.Net构建三层式Web 应用程序” 系列文章的第一部分。在这一系列文章中，我将系统的讲述如何使用 Asp.Net 设计、构建、实现三层式Web应用程序。本文的读者应该是有一定Asp.Net基础的开发者，同时要求对数据库、C#、Ajax、Web Service也有一定的了解。这系列文章使用我目前正在使用的一个“个人理财程序”作为范例讲解，这个程序非常小，只有三个表，但麻雀虽小五脏俱全，我主要想利用它为大家阐明一些概念，可能功能并不完备，但对于教程所讨论的主题没有影响，感兴趣的话可以自行扩展它。

古人云：条条大道通罗马。所以，我这里讲述的，只是我个人的三层式Web应用程序实现，并不是说只有这一种实现方法，也不能说明这种实现方法是最好的。

这系列文章计划分为五个部分，其中每个部分的内容如下：
Part 1. 讲解三层式Web应用程序的概念，数据访问层的实现方式，“个人理财程序”的程序介绍以及需求分析。
Part 2. 讲解系统的概要、详细设计，数据库的实现，业务层对象类的实现步骤和方法。
Part 3. 讲解数据访问层和业务逻辑层的代码实现。
Part 4. 讲解用户界面层的实现，以及如何使用 ObjectDataSource 调用业务逻辑层中的对象和方法。
Part 5. 讲解如何为 Part 4. 中实现的部分加上 Web Service 和 Asp.Net Ajax。

以下是几点说明：

本文中，我有时候会说到“用户界面层”，有时候会说到“表现层”，这两个在本系列文章中是一回事。
阅读本文前推荐阅读我的另一篇文章数据库对象命名参考。
本系列文章的 Source Code 和 T-SQL 脚本将会在所有Part全部发布后提供下载。

本系列文章使用的开发环境是 VS 2005 + SQL Server 2000，操作系统是 Windows Server 2003 Enterprise Edition。T-SQL 代码我只在 SQL Server 2000 下测试了，如果在 SQL Server 2005下不能通过，请反馈给我。

三层式开发介绍

分层式开发是一种开发模式，在这种模式中，用户界面层(用户所看到和与其交互的那部分)、业务逻辑层(业务规则(比如本例中每天的开销不能为负数)和业务对象)、以及数据访问层(对数据库进行查询和操作)，从代码的角度来看，是分开的。

这种模式具有很多的优点：

你的代码非常的“干净”。可以试想一下，如果你把提交表单的ADO.NET数据库操作全都写到页面的 CodeBehind文件中，会是多么的凌乱？
更好的可维护性，程序员之间的分工明确，各层之间只需要知道调用接口就可以了，而不需要知道是如何实现的。
更好的可移植性，可以联想一下微软的数据访问技术从 ODBC 到 OLEDB 到 ADO再到 ADO.Net 1.1 一直到如今的 ADO.NET 2.0，几乎每三年就会有一次变革，采用分层式开发，可以在系统升级的时候更少的受到影响。
更好的对分布式应用程序的支持。

NOTE：提到分布式应用程序时常会遇到两个英文单词: Tier 和 Layer ，这两个单词的意思翻译过来都是 “层”，但是有什么区别呢？老外通常提到Tier 的时候，指的是物理上分层；提到 Layer 的时候，常指的是逻辑上分层。物理上分层说的简单点，就是用户界面层在一台服务器，业务逻辑层在一台服务器，数据访问层又在另一台服务器(也可以表现层和业务层在同一台服务器，数据访问层在一台服务器，总之三个层不在一台服务器)。而逻辑上分层我现在正在讲述，很容易就想得通：如果物理上分层了，逻辑上也一定分层了；但如果逻辑上分层了，物理上不一定是分层的，可以部署在同一台服务器上，比如我的这个“个人理财程序”。

为了给大家一个更生动的认识，我用 Visio画了个图给大家看看：

图1. 三层式程序结构图

这张图描述了这个应用程序中数据流动的大致方向。

请大家从用户和左边的箭头看起：

用户浏览网页时，首先面对的是用户界面层或者说表现层，如果用户进行一个对数据库查询的操作，请求首先会发送到业务逻辑层。
业务逻辑层对用户提交的数据进行校验，如果有问题，将拒绝用户请求并给出错误提示；如果没有问题，业务逻辑层将用户请求递交给数据访问层。
+数据访问层充当业务逻辑层与数据库之间的一个桥梁，把请求递交给数据库，不应该在这一层再去做一些数据校验的工作，来自业务逻辑层的数据应该被认为是无误的，这层的代码相对于业务逻辑层来说是很清爽的。
数据库进行查询后将结果集返回给数据访问层，接着再返回给业务逻辑层，最后呈现给用户。这是一个典型的冒泡过程。在这个过程中，任何没有Catch的异常都会抛出，冒泡到用户界面层，这也就是为什么你访问aspx的页面，看到的却是来自数据库的“Can’t connect to database”的原因。

个人理财Web程序介绍

我是一个不会理财的人，在过去两年零一个月的时间，一毛钱都没有攒下，一个人的时候，我时常思索为什么我的钱总是来也匆匆去也匆匆，在现在老婆房子女朋友都没有的三无情况下，这样继续下去将会给我的人生带来深远的影响。

沉默了许久之后，我终于觉悟了... ..我想做的第一件事，就是解决长期困扰我的头号问题 -– 我的钱都跑哪儿去了？于是，这个个人理财程序便应运而生了。

其实如果只是我一个人使用的话，只需要一个表，就足以构建这个应用程序了。我给这个表起名叫：DailyCost，用来记录每天的开销/收入项目，表的字段分别是：

CostId：自动编号，主键。
Type：0，表示开销；1，表示收入
Purpost：开销用途/收入来源
Amount：数额
CostDate：开销日期

但是，这么好的程序(NOTE：和我一样不会理财的人应该也不少吧?)，只有我一个人用简直太浪费了，让我们来对它进行了一下扩展，让更多的人可以使用吧。这样，就很有必要再加一个 User 表，记录使用此系统的用户，这个表应该包含如下字段：

UserId：自动编号，主键。
Name：用户的名字
BirthDay：生日
Phone：用户的电话

此时，应该修改DailyCost表，以实现参照完整性(NOTE：也叫外键约束)。给DailyCost表再加一个字段：FKUserId，此条消费记录是属于哪位用户的。

在现在这个苦力都拿手机的时代，人们的Phone是会有很多的，比如手机一个，办公室一个，家里一个。所以，我们应该把Phone字段抽象出来，形成与User表的一对多关系。

建立 Phone 表，字段如下：
PhoneId：自动编号，主键。
Number：号码
Type：0，手机；1，家里；2，公司；3，其他
FKUserId：外键，此Phone是哪位用户的

OK，这部分就先介绍到这里，在后面的概要/详细设计中会再次讲解。

NOTE：概要设计和详细设计我合并了，因为这个应用程序比较小，合并到一起我想大家已经可以看明白，分开讲解可能会显得文章过于繁琐。

实现数据访问层的不同方式

与用户界面揉在一起的数据访问层

这就是上面提到过的“初学者访问层”，将ADO.NET 代码揉到CodeBehind的事件处理中去，这种方法几乎没有可维护性，对数据库的任何改动，比如增减一个字段，或者给某个存储过程重新命名，都要导致修改大量的相关文件。另外，这种方法还有一个致命的缺点：无法实现代码重用。其实这种方法不应该称作“层”，但是为了文章的完备性，我还是在这里把它提出来。

用这种方式写的代码通常都是这样的：

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 作为数据访问层

在这里我推荐给大家一本好书，由电子工业出版社出版的，奚江华写作的《圣殿祭祀的ASP.NET 2.0开发详解》。在这本书中，作者在第11章 — “新一代数据访问方式DataSource控件”中详细讨论了 SqlDataSource 的种种特性，其中，比较重要的就是使用代码后置的方法动态的创建和配置 SqlDataSource 控件，并提供对页面数据控件的绑定。这就提供了一种新的实现数据访问层的思路 – 使用SqlDataSource 作为数据访问层。

在这里不得不说明一点，ObjectDataSource 其实就是完全自定义的 SqlDataSource 控件，想想看你是如何使用 SqlDataSource 的？我想你一定在前端页面通过拖拽控件的方式使用过SqlDataSource ，也一定注意到 SqlDataSource 的几个重要属性，SelectCommand、UpdateCommand 等，在使用 SqlDataSource 时，向导自动为你生成 Sql 语句(也可以自己写)，然后显示在.aspx文件中，如果你实现了 UpdateCommand、InsertCommand (SelectCommand是必须要实现的)，SqlDataSource 也就具有了相应的功能。而 ObjectDataSource 是如何运作的呢？它要求你自己写全部的Code以实现 Command，区别就是，你可以把这些Command全部封装到类或者说业务逻辑层中去。

好了，说了这么多，让我们看看使用SqlDataSource作为数据访问层的典型页面吧。

<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>

很明显就可以看到，不仅关于数据访问的Sql 语句直接写到了 .aspx页面中，而且代码臃肿不堪。尽管你可以使用代码后置的方式去实现这些，但代价就是降低了开发效率，因为手写比你拖动控件、使用向导要慢得太多。

使用TableAdapter和强类型的DataSet

VS 2005 提供强类型的 DataSet ，可以通过 VS2005向导来创建，熟练的话，是创建数据访问层最快的一种方式，微软官方站点 http://www.asp.net/ ，有一个关于数据访问的系列教程，目前出到快 70 章了(NOTE：我大概算了一下，可以出本900页的书了)，仍在不断更新中，这个教程使用的就是这种模型。

这里我仅简要说明一下什么是强类型的DataSet，和普通的DataSet有什么区别，至于如何创建强类型的DataSet，需要一个独立的章节来介绍，我以后再发文章补上。

强类型DataSet(Typed DataSet)并不是 .NET 框架直接提供的一系列类，而是从DataSet类继承而来的，下图先给大家演示了传统的DataSet和它包含的各个元素之间的关系。

这里黑色的菱形箭头表示的是合成的方向，下面这幅图中，空心的三角，表示的是泛化的方向。合成，说通俗一点，或者用数据库的术语来说(NOTE: 用在这里并不恰当，纯粹为了解说方便)，就是多对一关系，拿这幅图来说，就是好多个 DataRow 合成了DataTable，同时DataTable 还可以有DataColumn，Constraint和DataRelation；同时，很多个DataColumn又合成了Constraint和DataRelation。最后，好多个DataTable和 DataRelation合成了DataSet。

相比之下，强类型DataSet是从这些类派生出来的。

这幅图该如何解读我就不详细解释了，留给大家一点思考的空间。

那又为什么称它们为“强类型”DataSet呢？因为在强类型DataSet中，是使用一种类型安全的方式来使用其中的每一个对象，光是说术语很难懂什么叫类型安全的方式，让我们看下面的代码范例吧。

我们先看一段使用传统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());

可以发现，我们在获取一个字段的值时，需要使用DataSet的索引器，逐步获得DataSet层次结构的每一个片段，直到最后抵达行级，在这个过程中，任何的拼写错误都会导致抛出异常。

现在再看看强类型DataSet是如何运作的。

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

//DailyCostTD 是实现了的强类型dataSet，至于如何实现，我以后会另写文章
DailyCostTD dataSet = new DailyCostTD();

daDailyCost.Fill(dataSet,”ShowCost”);

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

在这里，大家似乎觉得这两个没太大区别，无非就是在 Console.WriteLine的时候少打几个字而已，其实不然，在你用强类型DataSet的时候，VS2005会提供智能提示(NOTE：就是打个i，int就显示出来了，你只要拍下空格就好了)，这样，就大大降低了编写时发生手误的机会。

既然强类型DataSet这么好用，为什么不干脆使用它作为数据访问层呢？前面我也提到过，使用类型化DataSet是创建数据访问层最快的方式，你只需要建立一个.xsd数据集文件，然后拖拽控件，再使用向导设置一下基本就可以Run了。但是，代价就是几乎没有扩展性，因为代码都是自动生成的，你很难去修改它(NOTE：其实还是有办法可以改的，你可以通过写部分类的方式去扩展它)，另外，重用性也比较差。

使用封装的ADO.NET数据访问层类

与“初学者访问层”相同的地方是：这种方式也是采用的全手写 ADO.NET 代码来实现的；不同的是，将所有对于数据库的操作封装到了一个类中，这个类是高度整合的，你甚至可以不加改动将它用在其它的项目中。

我能想到这种方式，当然很多人也能想到，所以，网上的开源站点及一些个人站点已经提供了这个封装好的类的下载，其中大多是静态类，因为类作者水平高低不均，所以类的质量也是良莠不齐。另外，几乎所有这个类都约定俗成般起了同一个名字，叫做 -- SqlHelper 。

这里有一个比较不错的老外写的 SqlHelper类，感兴趣的可以参考一下。

使用新一代的 LINQ

还有一种方式就是使用LINQ，很多人可能还是第一次听说这个名词，那么我就稍微的介绍一下：

简单来说，Linq 就是帮助编译器理解和实现内存中保存的对象集合的一组特性。这样说可能比较绕口，Linq中有一个组件，称做Linq To Sql，它提供了一个在运行时将关系数据库数据处理成对象的底层机制，并且还不丧失关系数据库的查询功能。它通过将面向语的查询翻译成数据库可执行的查询语句，再将语句提交给数据库，然后把数据库返回的结果集映射成开发者定义的对象来完成。

上面的说法如果没有实际动手体会一下，或者看一些范例，相信不是太好理解。在我的个人博客 jimmyzhang.cnblogs.com 上已经陆续发布了来自微软开发团队的ScottGu的“Linq To Sql介绍”系列文章，有兴趣的朋友可以去看一看。

不使用Linq的主要原因是它现在还处于Beta版本，正式发布时可能还会有改进。另外，目前的主机大多都只支持到.Net Framework 2.0，所以使用LINQ尚为时过早。

使用自定义的业务逻辑层对象

终于，我们的主角登场了。很多情况下，业务对象只是一个由其他对象继承的简单的类，也可以实现一些接口让它变得更好用一些。在我们的这个系统中，Phone对象像下面这样：

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

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

在实践中，通常业务对象只包含数据，而关于对象操作的方法则封装到业务逻辑中去。

好了，数据访问层的实现方法至此告一段落，下面让我们开始进行需求分析吧。

需求分析

做任何开发之前，需求分析都是很重要的步骤，如果需求都没有搞好，就等于没有回答用户需要什么解决方案的问题，如果在需求分析不明确的情况下冒然进行开发，结果往往是苦战两个月，做出来的产品却不是用户想要的。另外，需求分析并不是一次成型的，在这个阶段，由于还没有深入到概要设计或者详细设计中去，对系统的理解可能并不完整，所以会时常回过头来修订需求分析。

由于这个“个人理财程序”的用户和开发人员都是我自己，所以需求分析可以认为只是打打字而已。

在这个Web应用程序中，我们要实现的功能主要有这些：