ASP.NET 2.0数据教程之二：创建一个业务逻辑层

系列文章导航：

ASP.NET 2.0数据教程之一：创建一个数据访问层

ASP.NET 2.0数据教程之二：创建一个业务逻辑层

ASP.NET 2.0数据教程之三：母板页和站点导航

ASP.NET 2.0数据教程之四：使用ObjectDataSource展现数据

ASP.NET 2.0数据教程之五：声明参数

ASP.NET 2.0数据教程之六：编程设置ObjectDataSource的参数值

ASP.NET 2.0数据教程之七：使用DropDownList过滤的主/从报表

ASP.NET 2.0数据教程之八：使用两个DropDownList过滤的主/从报表

ASP.NET 2.0数据教程之九：跨页面的主/从报表

ASP.NET 2.0数据教程之十：使用 GridView 和DetailView实现的主/从报表

ASP.NET 2.0数据教程之十一：基于数据的自定义格式化

ASP.NET 2.0数据教程之十二：在GridView控件中使用TemplateField

第四步：给BLL类添加业务规则

除了字段级的验证，可能还有一些不能在单个列中表示的包含不同实体或概念的更高级的业务规则，比如：

·         如果一个产品被标记为“停用”，那么它的单价就不能被修改

·         一个雇员的居住地必须与他（她）的主管的居住地相同

·         如果某个产品是某供应商唯一提供的产品，那么这个产品就不能被标记为“停用”

BLL类应该保证始终都验证应用程序的业务规则。这些验证可以直接的添加到应用他们的方法中。

想象一下，我们的业务规则表明了如果一个产品是给定的供应商的唯一产品，那么它就不能被标记为“停用”。也就是说，如果产品X是我们从供应商Y处购买的唯一一个产品，那么我们就不能将X标记为停用；然而，如果供应商Y提供给我们的一共有3样产品，分别是A、B和C，那么我们可以将其中任何一个或者三个全部都标记为“停用”。挺奇怪的业务规则，是吧？但是商业上的规则通常就是跟我们平常的感觉不太一样。

要在UpdateProducts方法中应用这个业务规则，那么我们就应该先检查Discontinued是否被设置为true。假如是这样的话，那么我们应该先调用GetProductsBySupplierID来看看我们从这个供应商处一共购买了多少产品。如果我们仅仅从这个供应商处购买了这一个产品，那么我们就抛出一个ApplicationException。

UpdateProduct
 1public 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{
 5        Northwind.ProductsDataTable products = Adapter.GetProductByProductID(productID);
 6        if (products.Count == 0)
 7            // 没有找到匹配项，返回false
 8            return false;
 9
10        Northwind.ProductsRow product = products[0];
11
12        // 业务规则检查 – 不能停用某供应商所提供的唯一一个产品
13        if (discontinued)
14        {
15            // 获取我们从这个供应商处获得的所有产品
16            Northwind.ProductsDataTable productsBySupplier = Adapter.GetProductsBySupplierID(product.SupplierID);
17
18            if (productsBySupplier.Count == 1)
19                // 这是我们从这个供应商处获得的唯一一个产品
20                throw new ApplicationException("You cannot mark a product as discontinued if its the only product purchased from a supplier");
21        }
22
23        product.ProductName = productName;
24        if (supplierID == null) product.SetSupplierIDNull(); else product.SupplierID = supplierID.Value;
25        if (categoryID == null) product.SetCategoryIDNull(); else product.CategoryID = categoryID.Value;
26        if (quantityPerUnit == null) product.SetQuantityPerUnitNull(); else product.QuantityPerUnit = quantityPerUnit;
27        if (unitPrice == null) product.SetUnitPriceNull(); else product.UnitPrice = unitPrice.Value;
28        if (unitsInStock == null) product.SetUnitsInStockNull(); else product.UnitsInStock = unitsInStock.Value;
29        if (unitsOnOrder == null) product.SetUnitsOnOrderNull(); else product.UnitsOnOrder = unitsOnOrder.Value;
30        if (reorderLevel == null) product.SetReorderLevelNull(); else product.ReorderLevel = reorderLevel.Value;
31        product.Discontinued = discontinued;
32
33        // 更新产品记录
34        int rowsAffected = Adapter.Update(product);
35
36        // 如果刚好更新了一条记录，则返回true，否则返回false
37        return rowsAffected == 1;
38}
39

在表示层中响应验证错误

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

我们将在后面的教程中看到，当通过一个数据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与他联系。