除了字段級的驗證，可能還有一些不能在單個列中表示的包含不同實體或概念的更高級的業務規則，比如：

·         如果一個產品被標記為“停用”，那么它的單價就不能被修改

·         一個雇員的居住地必須與他（她）的主管的居住地相同

·         如果某個產品是某供應商***提供的產品，那么這個產品就不能被標記為“停用”

ASP.NET 20.中，BLL類應該保證始終都驗證應用程序的業務規則。這些驗證可以直接的添加到應用他們的方法中。

想象一下，我們的業務規則表明了如果一個產品是給定的供應商的***產品，那么它就不能被標記為“停用”。也就是說，如果產品X是我們從供應商Y處購買的***一個產品，那么我們就不能將X標記為停用；然而，如果供應商Y提供給我們的一共有3樣產品，分別是A、B和C，那么我們可以將其中任何一個或者三個全部都標記為“停用”。挺奇怪的業務規則，是吧？但是商業上的規則通常就是跟我們平常的感覺不太一樣。

要在UpdateProducts方法中應用這個業務規則，那么我們就應該先檢查Discontinued是否被設置為true。假如是這樣的話，那么我們應該先調用GetProductsBySupplierID來看看我們從這個供應商處一共購買了多少產品。如果我們僅僅從這個供應商處購買了這一個產品，那么我們就拋出一個ApplicationException。

public bool UpdateProduct(string productName, int? supplierID, int? categoryID, string quantityPerUnit,  
                              decimal? unitPrice, short? unitsInStock, short? unitsOnOrder, short? reorderLevel,  
                              bool discontinued, int productID)  
{  
        Northwind.ProductsDataTable products = Adapter.GetProductByProductID(productID);  
        if (products.Count == 0)  
            // 沒有找到匹配項，返回false  
            return false;  
 
        Northwind.ProductsRow product = products[0];  
 
        // 業務規則檢查 – 不能停用某供應商所提供的***一個產品  
        if (discontinued)  
        {  
            // 獲取我們從這個供應商處獲得的所有產品  
            Northwind.ProductsDataTable productsBySupplier = Adapter.GetProductsBySupplierID(product.SupplierID);  
 
            if (productsBySupplier.Count == 1)  
                // 這是我們從這個供應商處獲得的***一個產品  
                throw new ApplicationException("You cannot mark a product as discontinued if its the only product purchased from a supplier");  
        }  
 
        product.ProductName = productName;  
        if (supplierID == null) product.SetSupplierIDNull(); else product.SupplierID = supplierID.Value;  
        if (categoryID == null) product.SetCategoryIDNull(); else product.CategoryID = categoryID.Value;  
        if (quantityPerUnit == null) product.SetQuantityPerUnitNull(); else product.QuantityPerUnit = quantityPerUnit;  
        if (unitPrice == null) product.SetUnitPriceNull(); else product.UnitPrice = unitPrice.Value;  
        if (unitsInStock == null) product.SetUnitsInStockNull(); else product.UnitsInStock = unitsInStock.Value;  
        if (unitsOnOrder == null) product.SetUnitsOnOrderNull(); else product.UnitsOnOrder = unitsOnOrder.Value;  
        if (reorderLevel == null) product.SetReorderLevelNull(); else product.ReorderLevel = reorderLevel.Value;  
        product.Discontinued = discontinued;  
 
        // 更新產品記錄  
        int rowsAffected = Adapter.Update(product);  
 
        // 如果剛好更新了一條記錄，則返回true，否則返回false  
        return rowsAffected == 1;  
}  

在表示層中響應驗證錯誤

當我們從表示層中調用BLL類時，我們可以決定是否要處理某個可能會被拋出的異常或者讓它直接拋給ASP.NET（這樣將會引發HttpApplication的出錯事件）。在使用BLL類的時候，如果要以編程的方式處理一個異常，我們可以使用try...catch塊，就像下面的示例一樣：

ProductsBLL productLogic = new ProductsBLL();  
   
 // 更新ProductID為1的產品信息  
 try 
 {  
     // 這個操作將會失敗，因為我們試圖使用一個小于0的UnitPrice  
     productLogic.UpdateProduct("Scott's Tea", 1, 1, null, -14m, 10, null, null, false, 1);  
 }  
 catch (ArgumentException ae)  
 {  
     Response.Write("There was a problem: " + ae.Message);  
 }  

我們將在后面的教程中看到，當通過一個數據Web控件（data Web Control）來進行插入、修改或刪除操作數據時，處理從BLL中拋出的異常可以直接在一個Event Handler中進行，而不需要使用try…catch塊來包裝代碼。

總結

一個具有良好架構的應用程序都擁有清晰的層次結構，每一個層次都封裝了一個特定的角色。在本教程的***篇中，我們用類型化數據集創建了一個數據訪問層；這一篇中，我們又建立了一個業務邏輯層，它由App_Code中一系列的類構成，并調用DAL中相應的方法。BLL類為我們的應用程序實現了字段級和業務級的邏輯。除了創建一個獨立的BLL，就像我們在本節中所做的那樣，另外一個選擇是使用partial類來擴展TableAdapter中的方法。然而，使用這個技術并不能使我們可以重寫已經存在的方法，也不能將我們的DAL和BLL分開得足夠清晰。

完成了DAL和BLL之后，我們就準備開始處理表示層了。在下一個教程中，我們將簡單的介紹一些數據訪問的主題，并為整個教程定義一個一致的頁面呈現。

【編輯推薦】

1. 如何在IIS6.0中部署asp.net mvc程序
2. 用Winform傻瓜式搭建asp.net mvc框架
3. ASP.NET Session失效的編程思路
4. ASP.NET Session 狀態的存儲
5. 了解ASP.NET Web應用程序模型