应用架构与改进呢

为数据断开的分布式体系结构的Web应用提供了支持。利用提供的对象化架构的特性为开发带来了便利，不幸的是，.NET 数据提供程序存在应用上的空白。本文分析了C#.NET应用架构中.NET数据提供程序的不足，通过挖掘DataSet组件的能力，因势利导，指出新的应用架构。

应用架构

在这个架构中（图1），为了开发的便利，使用了控件数据源绑定和DataAdapter数据自动更新。在获取数据的前端，返回了取每张表对应的DataAdapter和它们的DataSet。数据更新时，只需要使用DataAdapter的Update更新方法就可以了，它有数个重载的更新方法，其中一个只需要传递DataSet作为参数。

Update方法能自动生成InsertCommand，UpdateCommand和DeleteCommand命令，为了实现自动生成，需要为每个DataAdapter创建一个CommandBuilder。例子代码如下：

DA[i] = new SqlDataAdapter(sql[i], GetDBC());

作者： SqlCommandBuilder CB = new SqlCommandBuilder(DA[i]);

DA[i].Fill(DS, table[i]);

不幸的是，不能为每个DataAdapter指定共同的事务处理，换句话说，事务在中只能存在于单个表中。不仅如此，对于绑定的控件，不能产生自动生成的命令。为了实现绑定的控件能自动生成命令，需要挖掘DataSet的强大功能。

DataSet，DataTable和DataRow这些对象有一些重要的方法。它们都有一对共同的方法：RejectChanges和AcceptChanges。RejectChanges回滚自创建该对象以来对其进行的所有更改；AcceptChanges提交自加载此对象以来对其进行的所有更改。另外DataRow有一个重要的属性RowState，它指示了当前的状态。DataRowState有五种状态，它们是：Added，Deleted，Modified，Detached和Unchanged，这些都是该行在没有提交以前的状态。有了这些方法，让我们可以控制DataSet的数据和状态，对于绑定的控件，可以回滚绑定的事件对DataSet所做的更改，并置入修改后的值。这样，当我们使用DataAdapter更新时，SqlCommandBuilder就能够对那些需要更新的数据自动生成SQL命令。

这样如此烦琐的工作并不会影响到程序执行效率和开发效率。因为所有这些运算都是在客户机上执行的，并不会反映到络连接层；而且需要把执行的方法封装到类中，便于开发时调用。