ASP.NET2.0数据操作之创建业务逻辑层

　添加其他的类

　　完成了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方法的代码如下所示：

　　 UpdateSupplierAddress

1[System.ComponentModel.DataObjectMethodAttribute(System.ComponentModel.DataObjectMethodType.Update, true)] 2public bool UpdateSupplierAddress(int supplierID, string address, string city, string country) 3{ 4 Northwind.SuppliersDataTable suppliers = Adapter.GetSupplierBySupplierID(supplierID); 5 if (suppliers.Count == 0) 6 // 没有找到匹配的项，返回false 7 return false; 8 else 9 { 10 Northwind.SuppliersRow supplier = suppliers[0]; 11 12 if (address == null) supplier.SetAddressNull(); else supplier.Address = address; 13 if (city == null) supplier.SetCityNull(); else supplier.City = city; 14 if (country == null) supplier.SetCountryNull(); else supplier.Country = country; 15 16 // 更新供应商的关于地址的信息 17 int rowsAffected = Adapter.Update(supplier); 18 19 // 如果刚好更新了一条记录，则返回true，否则返回false 20 return rowsAffected == 1; 21 } 22} 23

　　可以从页面顶部的链接处下载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。

图三：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。

　　ProductsDataTable.ColumnChanging.cs

1public partial class Northwind 2{ 3 public partial class ProductsDataTable 4 { 5 public override void BeginInit() 6 { 7 this.ColumnChanging += ValidateColumn; 8 } 9 10 void ValidateColumn(object sender, DataColumnChangeEventArgs e) 11 { 12 if(e.Column.Equals(this.UnitPriceColumn)) 13 { 14 if(!Convert.IsDBNull(e.ProposedValue) && (decimal)e.ProposedValue < 0) 15 { 16 throw new ArgumentException("UnitPrice cannot be less than zero", "UnitPrice"); 17 } 18 } 19 else if (e.Column.Equals(this.UnitsInStockColumn) || 20 e.Column.Equals(this.UnitsOnOrderColumn) || 21 e.Column.Equals(this.ReorderLevelColumn)) 22 { 23 if (!Convert.IsDBNull(e.ProposedValue) && (short)e.ProposedValue < 0) 24 { 25 throw new ArgumentException(string.Format("{0} cannot be less than zero", e.Column.ColumnName), e.Column.ColumnName); 26 } 27 } 28 } 29 } 30}

　　第四步：给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块，就像下面的示例一样：

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之后，我们就准备开始处理表示层了。在下一个教程中，我们将简单的介绍一些数据访问的主题，并为整个教程定义一个一致的页面呈现。

查看本文来源