开发自己的Data Access Application Block[下篇]

下面来介绍重中之重：Database，绝大部分的Data Access 操作都集中在这个Abstract Database中。这是一个相对庞大的Class，所以不得不采用Partial Class的方式来编写。

Part I：Field 和Property

这些Field 和Property基本上对应我们前面的Configuraiton。此为我们定义了三个Field 和Property：DbDataAdapter，Connection，_transaction。考虑到垃圾回收，使Database实现IDisposable接口。值得说明一点的是，我们通过Database的DatabaseProviderFactory创建了泛型的DbDataAdapter，DbConnection和Transaction。

• ConnectionString：string
• DatabaseProviderFactory：DbProviderFactory
• DefaultCommandType：CommandType
• UseCommandBuilder：bool
• DbParameterNameMapping：IDbParameterNameMapping
• StoredProcedureNameMapping：IStoredProcedureNameMapping
• DbDataAdapter：DbDataAdapter
• Connection: DbConnection
• Transaction: DbTransaction

Part II: Fill Dataset

很简单，基本上ADO.NET 的基本操作，没什么可值得说的。

Part III Execute 系列

Part IV: Transaction

定义了3个基于Transaction的方法BeginTransaction，Commit和RollBack，使Developer显示地开始和结束一个Transaction，这样他可以很直观地把所需的操作纳入某个Transaction中。

Part V: Update

这一部分花了很多时间和精力，现看Code：

我们来分析一下 public void UpdateData(DataSet dataInfo)，这个方法对Data Access操作进行了高度的封装，Developer所做就是把更新过的Dataset传入UpdateData方法，其它的所有操作交给AppBlock来做。要实现这样的功能其实是很麻烦的，要考虑的因素很多：

• 需要把分析Dataset中DataTable之间的关系，确定先对那个Table 进行操作。
• Dataset中的数据包含不同DataRowState的记录：Added，Modified，Deleted；需要和Dataset中DataTable之间的关系结合确定不同表，不同DataRowState数据的操作顺序。
• 使用Stored Procedure进行更新，需要考虑以下的Mapping：DataTable的Name和Stored Procedure Name；不同DataRowVersion的DataRow中的Field和Stored Procedure中的参数名。

我的解决方案是：

为了避免数据库中数据的冲突，我们数据更新的顺序是：Deleted Data->Modified Data->Added Data;考虑到表之间的主子关系，对于Added Data和Modified Data，我们应该先修改Parent Table，后修改Child，而对Deleted Data顺序却恰好相反。由于我们 不应该对DataSet中的Table的数量和关系做出任何假设，我们需要以一种递归的过程完成数据的更新。本着这样一个原则，我们来看我们的实现：

整个过程分3步骤，更新Deleted data.-> 更新Modified data.-> 更新Added data.真正的数据更新集中在UpdateDependentTable这样一个方法中。

通过传入的DataRowState创建一个DataViewRowState变量。对于DataRowState.Added和DataRowState.Modified，通过ParentRelations属性递归地获得并修改Parent Table的数据，然后跟新本Table，最后通过ChildRelations属性递归地获得并更新Child Table，如果发现对应的表已经更新，忽略并进入下一步。对于DataRowState.Deleted，则是一种反向的方法进行操作。而最终的Data Access 又落在了UpdateIndependentTable(updatedRows)方法上面。

通过._useCommandBuilder 属性判断是通过使用CommandBuilder生成Command还是通过Mapped Stored Procedure来生成Command更新数据。

上面的是一个泛型的方法，我们可以对一个单独的Table的一个DataRow数组进行的更新，代码相对还算清晰，相信对大部分人没有难度：首先照例使用DatabaseProviderFactory创建泛型的DbCommandBuilder，指定SelectCommand的CommandText（Select * From TableName），通过DbCommandBuilder创建3个Command传递给DatabaseAdapter的3 个Command属性。如果用户开始了一个Transaction，则把创建的Transaction映射到3个Command上。最后调用DatabaseAdapter.Update方法实现 数据的跟新。通过DbCommandBuilder是一种很简单的方法，但是存在很大的性能问题。造成性能降低的主要原因有两个：他是使用纯文本的SQL；为了避免数据库的并发操作引起的数据不一致，它在作数据更新的时候，会逐个字段地把Dataset原始数据和数据库作比较。所以我们一边采用stored procedure来更新数据库。

通过stored procedure的方式和上面通过Command Builder的步骤差不多。首先通过Conection创建3个Command，并指定Command type为CommandType.StoredProcedure。通过storedProcedureNameMapping根据Table name获得对应的stored procedure的名称，并赋值给3个Command的CommandText属性。如果开始了Transaction，与之关联。通过DiscoverParameters方法（这个一个Abstract方法，需要在具体的Database 类脂Override）给Command发现参数。接着我们为3个Command的parameter指定SourceColumn和SourceVersion，其中SourceColumn通过我们配置的dbParameterNameMapping来获得。SourceVersion通过方法GetSourceVersion（这个一个Abstract方法，需要在具体的Database 类脂Override；这个方法根据参数名称来无额定对应的Source Version：Original or Current）来获取。最后调用DatabaseAdapter.Update方法实现 数据的跟新。

5. SQLDatabase & OracleDatabase

由于ADO.NET 2.0提供的很多基于泛型编程的功能，使得我们把觉得大部分Data Access操作放在了上面这个Abstract Database中，所以SQLDatabase & OracleDatabase上的逻辑很少。我们只看SQLDatabase。上面我们提到Abstract Database提供两个Abstract方法需要在具体的Database中实现的：DiscoverParameters和GetSourceVersion。实现上SQLDatabase之包含这两个方法：