ADO.NET实用经验汇总(4)

ADO.NET提供了几种命令执行的不同方法以及优化命令执行的不同选项。下面包括一些技巧,它们是关于选择最佳命令执行以及如何提高执行命令的性能。

使用OleDbCommand的最佳实践

不同.NET框架数据提供程序之间的命令执行被尽可能标准化了。但是,数据提供程序之间仍然存在差异。下面给出一些技巧,可微调用于OLE DB的.NET框架数据提供程序的命令执行。

1) 按照ODBC CALL语法使用CommandType.Text调用存储过程。使用CommandType.StoredProcedure只是秘密地生成ODBC CALL语法。

2) 一定要设置OleDbParameter的类型、大小(如果适用)、以及精度和范围(如果参数类型是numeric或decimal)。注意,如果不显式提供参数信息,OleDbCommand会为每个执行命令重新创建OLE DB参数访问器。

使用SqlCommand的最佳实践

使用SqlCommand执行存储过程的快速提示:如果调用存储过程,将SqlCommand的CommandType属性指定为StoredProcedure的CommandType。这样通过将该命令显式标识为存储过程,就不需要在执行之前分析命令。

使用Prepare方法

对于重复作用于数据源的参数化命令,Command.Prepare方法能提高性能。Prepare指示数据源为多次调用优化指定的命令。要想有效利用Prepare,需要彻底理解数据源是如何响应Prepare调用的。对于一些数据源(例如SQL Server 2000),命令是隐式优化的,不必调用Prepare。对于其他(例如SQL Server 7.0)数据源,Prepare会比较有效。

显式指定架构和元数据

只要用户没有指定元数据信息,ADO.NET的许多对象就会推断元数据信息。下面是一些示例:

1) DataAdapter.Fill方法,如果DataSet中没有表和列,DataAdapter.Fill方法会在DataSet中创建表和列。

2) CommandBuilder,它会为单表SELECT命令生成DataAdapter命令属性。

3) CommandBuilder.DeriveParameters,它会填充Command对象的Parameters集合。

但是,每次用到这些特性,都会有性能损失。建议将这些特性主要用于设计时和即席应用程序中。在可能的情况下,显式指定架构和元数据。其中包括在DataSet中定义表和列、定义DataAdapter的Command属性、以及为Command定义Parameter信息。

ExecuteScalar和ExecuteNonQuery

如果想返回像Count(*)、Sum(Price)或Avg(Quantity)的结果那样的单值,可以使用Command.ExecuteScalar。ExecuteScalar返回第一行第一列的值,将结果集作为标量值返回。因为单独一步就能完成,所以ExecuteScalar不仅简化了代码,还提高了性能;要是使用DataReader就需要两步才能完成(即,ExecuteReader+取值)。

使用不返回行的SQL语句时,例如修改数据(例如INSERT、UPDATE或DELETE)或仅返回输出参数或返回值,请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。

测试Null

如果表(在数据库中)中的列允许为空,就不能测试参数值是否“等于”空。相反,需要写一个WHERE子句,测试列和参数是否都为空。下面的SQL语句返回一些行,它们的LastName列等于赋给@LastName参数的值,或者LastName列和@LastName参数都为空。

SELECT * FROM Customers WHERE ((LastName = @LastName) OR (LastName IS NULL AND @LastName IS NULL))

将Null作为参数值传递

对数据库的命令中,当将空值作为参数值发送时,不能使用null(Visual Basic .NET中为Nothing)。而需要使用DBNull.Value。例如:

‘Visual Basic Dim param As SqlParameter = New SqlParameter(“@Name”, SqlDbType.NVarChar, 20) param.Value = DBNull.Value

//C# SqlParameter param = new SqlParameter(“@Name”, SqlDbType.NVarChar, 20); param.Value = DBNull.Value;

执行事务

ADO.NET的事务模型已经更改。在ADO中,当调用StartTransaction时,调用之后的任何更新操作都被视为是事务的一部分。但是,在ADO.NET中,当调用Connection .BeginTransaction时,会返回一个Transaction对象,需要将它与Command的Transaction属性联系起来。这种设计可以在一个单一连接上执行多个根事务。如果未将Command.Transaction属性设置为一个针对相关的Connection而启动的Transaction,那么Command就会失败并引发异常。

即将发布的.NET框架将使您可以在现有的分布式事务中手动登记。这对于对象池方案来说很理想;在该方案中,一个池对象打开一次连接,但是在多个独立的事务中都涉及到该对象。.NET框架1.0发行版中这一功能并不可用。

使用连接

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wdsywd.html