ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[2] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[3] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[4] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[5] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[6] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
[7] ASP.NET 2.0数据教程之二:创建一个业务逻辑层
系列文章导航:
ASP.NET 2.0数据教程之四:使用ObjectDataSource展现数据
ASP.NET 2.0数据教程之六:编程设置ObjectDataSource的参数值
ASP.NET 2.0数据教程之七:使用DropDownList过滤的主/从报表
ASP.NET 2.0数据教程之八:使用两个DropDownList过滤的主/从报表
ASP.NET 2.0数据教程之十:使用 GridView 和DetailView实现的主/从报表
ASP.NET 2.0数据教程之十一:基于数据的自定义格式化
ASP.NET 2.0数据教程之十二:在GridView控件中使用TemplateField
注意:当我们在添加或更新一个产品的详细信息时,都是接受由产品信息组成的一个标量列表,而不是直接接受一个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向导中的操作更加轻松和心情愉快。