在ASP.NET 2.0中操作数据：创建一个业务逻辑层
英文原版 | 本教程的代码(C#) | 翻译目录 | 原文目录
导言
本教程的第一节所描述的数据访问层（Data Access Layer，以下简称为DAL）已经清晰地将表示逻辑与数据访问逻辑区分开了。不过，即使DAL将数据访问的细节从表示层中分离出来了，可它却不能处理任何的业务规则。比如说，我们可能不希望产品表中那些被标记为“停用”的产品的“分类编号”或“供应商编号”被更新；我们还可能需要应用一些资历规则，比如说我们都不希望被比自己的资历还要浅的人管理。另外一个比较常见的情况就是授权，比如说只有那些具有特殊权限的用户可以删除产品或是更改单价。
我们其实可以将业务逻辑层（Business Logic Layer，以下简称BLL）看作是在数据访问层和表示层之间进行数据交换的桥梁，在这个章节中，我们将讨论一下如何将这些业务规则集成到一个BLL中。需要说明的是，在一个实际的应用程序中，BLL都是以类库（Class Library）的形式来实现的，不过为了简化工程的结构，在本教程中我们将BLL实现为App_Code文件夹中的一系列的类。图一向我们展示了表示层、BLL以及DAL三者之间的结构关系。
图一：BLL将表示层与DAL隔开了，并且加入了业务规则
第一步：创建BLL类
我们的BLL由4个类组成，每一个BLL类都对应DAL中的一个TableAdapter，它们都从各自的TableAdapter中得到读取、插入、修改以及删除等方法以应用合适的业务规则。
为了更加清晰的区分DAL和BLL的类，我们在App_Code文件夹中建立两个子文件夹，分别命名为DAL和BLL。你仅仅需要在解决方案浏览器（Solution Explorer）中右键点击App_Code文件夹，并选择新建文件夹（New Folder），就可以创建新的子文件夹了。建好了这两个文件夹之后，把第一节中所创建的类型化数据集（Typed DataSet）移到DAL文件夹中。
然后，在BLL文件夹中创建4个类文件。同样，你仅仅需要在解决方案浏览器（Solution Explorer）中右键点击BLL文件夹，并选择新建项目（New Item），然后在弹出的对话框中选择类模板（Class template）就可以创建新的类文件了。将这四个文件分别命名为ProductsBLL、CategoriesBLL、SuppliersBLL以及EmployeesBLL。
图二：在BLL文件夹中添加4个新的类
接下来，让我们来给这些新建的类加上一些方法，简单的将第一节中的TableAdapter中的那些方法包装起来就行了。现在，这些方法将只能直接使用DAL中的那些方法，我们等会再来给他们加上一些业务逻辑。
注意：如果你使用的是Visual Studio 标准版或以上版本（也就是说，你不是用的Visual Web Developer），那么你还可以使用Class Designer来可视化的设计你的类。你可以在Class Designer Blog上得到关于Visual Studio的这项新功能的详细信息。
在ProductsBLL类中，我们一共需要为其添加7个方法：
l GetProducts() – 返回所有的产品
l GetProductByProductID(productID) – 返回指定ProductID的产品
l GetProductsByCategoryID(categoryID) –返回指定分类的产品
l GetProductsBySupplier(supplierID) –返回指定供应商的产品
l AddProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued) – 向数据库中添加一条产品信息，并返回新添加的产品的ProductID
l UpdateProduct(productName, supplierID, categoryID, quantityPerUnit, unitPrice, unitsInStock, unitsOnOrder, reorderLevel, discontinued, productID) – 更新一个数据库中已经存在的产品，如果刚好更新了一条记录，则返回true，否则返回false
l DeleteProduct(productID) – 删除指定ProductID的产品
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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方法的代码如下所示：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
可以从页面顶部的链接处下载BLL类的完整代码。
第二步：通过BLL类访问类型化数据集
在本教程的第一节中，我们给出了直接使用类型化数据集的例子，不过在我们添加了BLL类之后，表示层就可以通过BLL来工作了。在本教程的第一节中的AllProducts.aspx的例子中，ProductsTableAdapter用于将产品列表绑定到GridView上，代码如下所示：
2 GridView1.DataSource = productsAdapter.GetProducts();
3 GridView1.DataBind();
要使用新的BLL类，我们所需要做的仅仅是简单的修改一下第一行代码。用ProductBLL对象来代替 ProductsTableAdapter即可：
2 GridView1.DataSource = productLogic.GetProducts();
3 GridView1.DataBind();
BLL类也可以通过使用ObjectDataSource来清晰明了的访问（就像类型化数据集一样）。我们将在接下来的教程中详细的讨论ObjectDataSource。
图三：GridView中显示的产品列表
第三步：给DataRow添加字段级验证
字段级验证是指在插入或更新时检查业务对象所涉及到的所有属性值。拿产品来举个例，某些字段级的验证规则如下所示：
· ProductName字段不得超过40个字符
· QuantityPerUnit字段不得超过20个字符
· ProductID、ProductName以及Discontinued字段是必填的，而其他字段则是可填可不填的
· UnitPrice、UnitsInStock、UnitsOnOrder以及ReorderLevel字段不得小于0
这些规则可以或者说是应该在数据库层被描述出来。ProductName和QuantityPerUnit字段上的字符数限制可以通过Products表中相应列的数据类型来实现（分别为nvarchar(40) and nvarchar(20)）。字段“是否必填”可以通过将数据库中表的相应列设置为“允许为NULL”来实现。为了保证UnitPrice、UnitsInStock、UnitsOnOrder以及ReorderLevel字段的值不小于0，可以分别在它们的相应列上加一个约束。
除了在数据库中应用了这些规则之外，它们同时也将被其应用在DataSet上。事实上，字段长度和是否允许为空等信息已经被应用到了各DataTable的DataColumn集合中。我们可以在数据集设计器（DataSet Designer）中看到已经存在的字段级验证，从某个DataTable中选择一个字段，然后在属性窗口中就可以找到了。如图四所示，ProductDataTable中的QuantityPerUnit字段允许空值并且最大长度为20各字符。如果我们试图给某个ProductsDataRow的QuantityPerUnit属性设置一个长度大于20个字符的字符串，将会有一个ArgumentException被抛出。
图四：DataColumn提供了基本的字段级验证
不幸的是，我们不能通过属性窗口指定一个边界检查，比如UnitPrice的值不能小于0。为了提供这样的字段级验证，我们需要为DataTable的ColumnChanging事件建立一个Event Handler。正如上一节教程中所提到的那样，由类型化数据集创建的DataSet、DataTable还有DataRow对象可以通过partial类来进行扩展。使用这个技术，我们可以为ProductDataTable创建一个ColumnChanging的Event Handler。我们先在App_Code文件夹中新建一个名为ProductsDataTable.ColumnChanging.cs的类文件，如下图所示。
图五：在App_Code文件夹中添加新类
然后，给ColumnChanging事件创建一个Event handler，以保证UnitPrice、UnitsInStock、UnitsOnOrder以及ReorderLevel字段的值不小于0。如果这些列的值超出范围就抛出一个ArgumentException。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
第四步：给BLL类添加业务规则
除了字段级的验证，可能还有一些不能在单个列中表示的包含不同实体或概念的更高级的业务规则，比如：
· 如果一个产品被标记为“停用”，那么它的单价就不能被修改
· 一个雇员的居住地必须与他（她）的主管的居住地相同
· 如果某个产品是某供应商唯一提供的产品，那么这个产品就不能被标记为“停用”
BLL类应该保证始终都验证应用程序的业务规则。这些验证可以直接的添加到应用他们的方法中。
想象一下，我们的业务规则表明了如果一个产品是给定的供应商的唯一产品，那么它就不能被标记为“停用”。也就是说，如果产品X是我们从供应商Y处购买的唯一一个产品，那么我们就不能将X标记为停用；然而，如果供应商Y提供给我们的一共有3样产品，分别是A、B和C，那么我们可以将其中任何一个或者三个全部都标记为“停用”。挺奇怪的业务规则，是吧？但是商业上的规则通常就是跟我们平常的感觉不太一样。
要在UpdateProducts方法中应用这个业务规则，那么我们就应该先检查Discontinued是否被设置为true。假如是这样的话，那么我们应该先调用GetProductsBySupplierID来看看我们从这个供应商处一共购买了多少产品。如果我们仅仅从这个供应商处购买了这一个产品，那么我们就抛出一个ApplicationException。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
在表示层中响应验证错误
当我们从表示层中调用BLL时，我们可以决定是否要处理某个可能会被抛出的异常或者让它直接抛给ASP.NET（这样将会引发HttpApplication的出错事件）。在使用BLL的时候，如果要以编程的方式处理一个异常，我们可以使用try...catch块，就像下面的示例一样：
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。他的联系电邮为[email protected]，也可以通过他的博客http://ScottOnWriting.NET与他联系。
转载请注明本文地址： [翻译]Scott Mitchell 的ASP.NET 2.0数据教程之二：创建一个业务逻辑层