[翻译]Scott Mitchell 的ASP.NET 2.0数据教程之二：创建一个业务逻辑层

在ASP.NET 2.0中操作数据：创建一个业务逻辑层

英文原版 | 本教程的代码(C#) | 翻译目录 | 原文目录

导言
本教程的第一节所描述的数据访问层（Data Access Layer，以下简称为DAL）已经清晰地将表示逻辑与数据访问逻辑区分开了。不过，即使DAL将数据访问的细节从表示层中分离出来了，可它却不能处理任何的业务规则。比如说，我们可能不希望产品表中那些被标记为“停用”的产品的“分类编号”或“供应商编号”被更新；我们还可能需要应用一些资历规则，比如说我们都不希望被比自己的资历还要浅的人管理。另外一个比较常见的情况就是授权，比如说只有那些具有特殊权限的用户可以删除产品或是更改单价。

我们其实可以将业务逻辑层（Business Logic Layer，以下简称BLL）看作是在数据访问层和表示层之间进行数据交换的桥梁，在这个章节中，我们将讨论一下如何将这些业务规则集成到一个BLL中。需要说明的是，在一个实际的应用程序中，BLL都是以类库（Class Library）的形式来实现的，不过为了简化工程的结构，在本教程中我们将BLL实现为App_Code文件夹中的一系列的类。图一向我们展示了表示层、BLL以及DAL三者之间的结构关系。

using System;
2using System.Data;
3using System.Configuration;
4using System.Web;
5using System.Web.Security;
6using System.Web.UI;
7using System.Web.UI.WebControls;
8using System.Web.UI.WebControls.WebParts;
9using System.Web.UI.HtmlControls;
10using NorthwindTableAdapters;
11
12[System.ComponentModel.DataObject]
13public class ProductsBLL
14

GetProducts、GetProductByProductID、GetProductsByCategoryID以及 GetProductBySuppliersID等方法都仅仅是简简单单的直接调用DAL中的方法来返回数据。不过在有的情况下，我们还可能需要给它们实现一些业务规则（比如说授权规则，不同的用户或不用角色应该可以看到不同的数据），现在我们简单的将它们做成这样就可以了。那么，对于这些方法来说，BLL仅仅是作为表示层与DAL之间的代理。

AddProduct和UpdateProduct这两个方法都使用参数中的那些产品信息去添加或是更新一条产品记录。由于Product表中有许多字段都允许空值（CategoryID、SupplierID、UnitPrice……等等），所以AddProduct和UpdateProduct中相应的参数就使用nullable types。Nullable types是.NET 2.0中新提供的一种用于标明一个值类型是否可以为空的技术。在C#中，你可以在一个允许为空的值类型后面加上一个问号（比如，int? x;）。关于Nullable Types的详细信息，你可以参考C# Programming Guide。

由于插入、修改和删除可能不会影响任何行，所以这三种方法均返回一个bool值用于表示操作是否成功。比如说，页面开发人员使用一个并不存在的ProductID去调用DeleteProduct，很显然，提交给数据库的DELETE语句将不会有任何作用，所以DeleteProduct会返回false。

注意：当我们在添加或更新一个产品的详细信息时，都是接受由产品信息组成的一个标量列表，而不是直接接受一个ProductsRow实例。因为ProductsRow是继承于ADO.NET的DataRow，而DataRow没有默认的无参构造函数，为了创建一个ProductsRow的实例，我们必须先创建一个ProductsDataTable的实例，然后调用它的NewProductRow方法（就像我们在AddProduct方法中所做的那样）。不过，当我在使用ObjectDataSource来插入或更新时，这样做的缺点就会暴露出来了。简单的讲，ObjectDataSource会试图为输入的参数创建一个实例，如果BLL方法希望得到一个ProductsRow，那么ObjectDataSource就将会试图去创建一个，不过很显然，这样的操作一定会失败，因为没有一个默认的无参构造函数。这个问题的详细信息，可以在ASP.NET论坛的以下两个帖子中找到: Updating ObjectDataSources with Strongly-Typed DataSets、Problem With ObjectDataSource and Strongly-Typed DataSet。

之后，在AddProduct和UpdateProduct中，我们创建了一个ProductsRow实例，并将传入的参数赋值给它。当给一个DataRow的DataColumns赋值时，各种字段级的有效性验证都有可能会被触发。因此，我们应该手工的验证一下传入的参数以保证传递给BLL方法的数据是有效的。不幸的是，Visual Studio生成的强类型数据集（strongly-typed DataRow）并没有使用nullable values。要表明DataRow中的一个DataColumn可以接受空值，我们就必须得使用SetColumnNameNull方法。

在UpdateProduct中，我们先使用GetProductByProductID(productID)方法将需要更新的产品信息读取出来。这样做好像没有什么必要，不过我们将在之后的关于并发优化（Optimistic concurrency）的课程中证明这个额外的操作是有它的作用的。并发优化是一种保证两个用户同时操作一个数据而不会发生冲突的技术。获取整条记录同时也可以使创建一个仅更新DataRow的一部分列的方法更加容易，我们可以在SuppliersBLL类中找到这样的例子。

最后，注意我们在ProductsBLL类上面加上了DataObject 标签（就是在类声明语句的上面的[System.ComponentModel.DataObject]），各方法上面还有DataObjectMethodAttribute 标签。DataObject标签把这个类标记为可以绑定到一个ObjectDataSource控件，而DataObjectMethodAttribute则说明了这个方法的目的。我们将在后面的教程中看到，ASP.NET 2.0的ObjectDataSource使从一个类中访问数据更加容易。为了ObjectDataSource向导能够对现有的类进行合适的筛选，在类列表中默认仅显示标记为DataObject的类。当然，其实ProductsBLL类就算没有这个标签也可以工作，但是加上它可以使我们在ObjectDataSource向导中的操作更加轻松和心情愉快。

添加其他的类


完成了ProductsBLL类之后，我们还要添加一些为categories、suppliers和employees服务的类。让我们花点时间来创建下面的类，根据上面的例子来做就是了：

· CategoriesBLL.cs

o GetCategories()

o GetCategoryByCategoryID(categoryID)



· SuppliersBLL.cs

o GetSuppliers()

o GetSupplierBySupplierID(supplierID)

o GetSuppliersByCountry(country)

o UpdateSupplierAddress(supplierID, address, city, country)



· EmployeesBLL.cs

o GetEmployees()

o GetEmployeeByEmployeeID(employeeID)

o GetEmployeesByManager(managerID)

SuppliersBLL类中的UpdateSupplierAddress方法是一个值得注意的东西。这个方法提供了一个仅仅更新供应商地址信息的接口。它首先根据指定的SupplierID读出一个SupplierDataRow(使用GetSupplierBySupplierID方法)，设置其关于地址的所有属性，然后调用SupplierDataTable的Update方法。UpdateSupplierAddress方法的代码如下所示：

[System.ComponentModel.DataObjectMethodAttribute(System.ComponentModel.DataObjectMethodType.Update, true)]
2public bool UpdateSupplierAddress(int supplierID, string address, string city, string country)
3

可以从页面顶部的链接处下载BLL类的完整代码。

第二步：通过BLL类访问类型化数据集

在本教程的第一节中，我们给出了直接使用类型化数据集的例子，不过在我们添加了BLL类之后，表示层就可以通过BLL来工作了。在本教程的第一节中的AllProducts.aspx的例子中，ProductsTableAdapter用于将产品列表绑定到GridView上，代码如下所示：

1 ProductsTableAdapter productsAdapter = new ProductsTableAdapter();
2 GridView1.DataSource = productsAdapter.GetProducts();
3 GridView1.DataBind();

要使用新的BLL类，我们所需要做的仅仅是简单的修改一下第一行代码。用ProductBLL对象来代替 ProductsTableAdapter即可：

1 ProductsBLL productLogic = new ProductsBLL();
2 GridView1.DataSource = productLogic.GetProducts();
3 GridView1.DataBind();

BLL类也可以通过使用ObjectDataSource来清晰明了的访问（就像类型化数据集一样）。我们将在接下来的教程中详细的讨论ObjectDataSource。

public partial class Northwind
2public bool UpdateProduct(string productName, int? supplierID, int? categoryID, string quantityPerUnit,
2 decimal? unitPrice, short? unitsInStock, short? unitsOnOrder, short? reorderLevel,
3 bool discontinued, int productID)
4

在表示层中响应验证错误

当我们从表示层中调用BLL时，我们可以决定是否要处理某个可能会被抛出的异常或者让它直接抛给ASP.NET（这样将会引发HttpApplication的出错事件）。在使用BLL的时候，如果要以编程的方式处理一个异常，我们可以使用try...catch块，就像下面的示例一样：

1 ProductsBLL productLogic = new ProductsBLL();
2
3 // 更新ProductID为1的产品信息
4 try
5 {
6 // 这个操作将会失败，因为我们试图使用一个小于0的UnitPrice
7 productLogic.UpdateProduct("Scott's Tea", 1, 1, null, -14m, 10, null, null, false, 1);
8 }
9 catch (ArgumentException ae)
10 {
11 Response.Write("There was a problem: " + ae.Message);
12 }

我们将在后面的教程中看到，当通过一个数据Web控件（data Web Control）来进行插入、修改或删除操作数据时，处理从BLL中抛出的异常可以直接在一个Event Handler中进行，而不需要使用try…catch块来包装代码。

总结

一个具有良好架构的应用程序都拥有清晰的层次结构，每一个层次都封装了一个特定的角色。在本教程的第一篇中，我们用类型化数据集创建了一个数据访问层；这一篇中，我们又建立了一个业务逻辑层，它由App_Code中一系列的类构成，并调用DAL中相应的方法。BLL为我们的应用程序实现了字段级和业务级的逻辑。除了创建一个独立的BLL，就像我们在本节中所做的那样，另外一个选择是使用partial类来扩展TableAdapter中的方法。然而，使用这个技术并不能使我们可以重写已经存在的方法，也不能将我们的DAL和BLL分开得足够清晰。

完成了DAL和BLL之后，我们就准备开始处理表示层了。在下一个教程中，我们将简单的介绍一些数据访问的主题，并为整个教程定义一个一致的页面呈现。

编程愉快！

关于作者

Scott Mitchell，著有六本ASP/ASP.NET方面的书，是4GuysFromRolla.com的创始人，自1998年以来一直应用微软Web技术。Scott是个独立的技术咨询顾问，培训师，作家，最近完成了将由Sams出版社出版的新作，24小时内精通ASP.NET 2.0。他的联系电邮为mitchell@4guysfromrolla.com，也可以通过他的博客http://ScottOnWriting.NET与他联系。