【简介】 | ||||||||||||
ADO.NET作为微软最新的数据访问技术,已经在企业开发中得到了广泛的应用。对于一线的开发人员来说,掌握基本的概念和技术之后,提高应用水平和解决实际问题的最有效手段,莫过于相互交流彼此的最佳时间经验经验。在这篇文章中,两位ADO.NET专家向读者毫无保留地、详尽地介绍了很多实用经验。 | ||||||||||||
本文为您提供了在Microsoft ADO.NET应用程序中实现和获得最佳性能、可伸缩性以及功能的最佳解决方案;同时也讲述了使用ADO.NET中可用对象的最佳实践;并提出一些有助于优化ADO.NET应用程序设计的建议。 | ||||||||||||
本文包括
| ||||||||||||
.NET框架数据提供程序 | ||||||||||||
.NET框架中的数据提供程序(Data Provider)在应用程序和数据源之间起到桥梁作用。.NET框架数据提供程序能够从数据源中返回查询结果、对数据源执行命令、将DataSet中的更改传播给数据源。本文包括有关哪个.NET框架数据提供程序是最适合您需要的一些技巧。 | ||||||||||||
使用哪个.NET框架数据提供程序? | ||||||||||||
为了使您的应用程序获得最佳性能,请使用最适合您的数据源的.NET框架数据提供程序。有许多数据提供程序可供您的应用程序选用。下表(见下页)提供了关于可用数据提供程序的信息,以及每个数据提供程序最适合哪个数据源。 | ||||||||||||
连接到SQL Server 7.0或更高版本 | ||||||||||||
为了在连接到Microsoft SQL Server 7.0或更高版本时获得最佳性能,请使用SQL Server .NET数据提供程序。SQL Server .NET数据提供程序的设计目的就在于不通过任何附加技术层就可以直接访问SQL Server。图1说明了可用于访问SQL Server 7.0或更高版本的不同技术之间的区别。 | ||||||||||||
连接到ODBC数据源 | ||||||||||||
ODBC .NET数据提供程序可在Microsoft.Data.ODBC命名空间中找到,它的体系结构与用于SQL Server和OLE DB的.NET数据提供程序相同。ODBC .NET数据提供程序遵循命名约定-以“ODBC”为前缀(例如,OdbcConnection),并使用标准ODBC连接字符串。 | ||||||||||||
使用DataReader、DataSet、DataAdapter和DataView | ||||||||||||
ADO.NET提供以下两个对象,用于检索关系数据并将其存储在内存中:DataSet和DataReader。DataSet提供一个内存中数据的关系表示形式,一整套包括一些表在内的数据(这些表包含数据、对数据进行排序并约束数据),以及表之间的关系。DataReader提供一个来自数据库的快速、仅向前、只读数据流。 | ||||||||||||
当使用DataSet时,经常会利用DataAdapter(也可能是CommandBuilder)与数据源进行交互。当使用DataSet时,也可以利用DataView对DataSet中的数据应用排序和筛选。也可以从DataSet继承,创建强类型DataSet,用于将表、行和列作为强类型对象属性公开。 | ||||||||||||
下列主题包括的信息涉及:使用DataSet或DataReader的最佳时机、如何优化访问它们所包含数据、以及如何优化使用DataAdapter(包括CommandBuilder)和DataView的技巧。 | ||||||||||||
DataSet与DataReader | ||||||||||||
当设计应用程序时,要考虑应用程序所需功能的等级,以确定使用DataSet或者是DataReader。 | ||||||||||||
要通过应用程序执行以下操作,就要使用DataSet:
| ||||||||||||
对于下列情况,要在应用程序中使用DataReader:
| ||||||||||||
注填充DataSet时,DataAdapter使用DataReader。因此,使用DataAdapter取代DataSet提升的性能表现为节省了DataSet占用内存和填充DataSet需要的循环。一般来说,此性能提升只是象征性的,因此,设计决策应以所需功能为基础。 | ||||||||||||
使用强类型DataSet的好处 | ||||||||||||
DataSet的另一个好处是可被继承以创建一个强类型DataSet。强类型DataSet的好处包括设计时类型检查,以及Microsoft Visual Studio.NET用于强类型DataSet语句结束所带来的好处。修改了DataSet的架构或关系结构后,就可以创建一个强类型DataSet,将行和列作为对象的属性公开,而不是作为集合中的项公开。例如,不公开客户表中行的姓名列,而公开Customer对象的Name属性。类型化DataSet从DataSet类派生,因此不会牺牲DataSet的任何功能。也就是说,类型化DataSet仍能远程访问,并作为数据绑定控件(例如DataGrid)的数据源提供。如果架构事先不可知,仍能受益于通用DataSet的功能,但却不能受益于强类型DataSet的附加功能。 | ||||||||||||
处理强类型DataSet中的空引用 | ||||||||||||
使用强类型DataSet时,可以使用DataSet的XML架构定义语言(XSD)架构来确保强类型DataSet可以正确处理空引用。nullValue标识符使您可用一个指定的值String.Empty代替DBNull、保留空引用或引发异常。选择哪个选项取决于应用程序的上下文。默认情况下,如果遇到空引用,就会引发异常。 | ||||||||||||
刷新DataSet中的数据 | ||||||||||||
如果想用服务器上的更新值刷新DataSet中的值,就使用DataAdapter.Fill。如果有在DataTable上定义的主键,DataAdapter.Fill会根据主键进行新行匹配,并且当更改到现有行时应用服务器上的值。即使刷新之前修改了这些数据,刷新行的RowState仍被设置为Unchanged。注意,如果没有为DataTable定义主键,DataAdapter.Fill就用可能重复的主键值添加新行。 | ||||||||||||
如果想用来自服务器的当前值刷新表,并同时保留对表中的行所做的任何更改,必须首先用DataAdapter.Fill填充表,并填充一个新的DataTable,然后用preserveChanges值true将DataTable合并到DataSet之中。 | ||||||||||||
在DataSet中搜索数据 | ||||||||||||
在DataSet中查询与特定条件相匹配的行时,可以利用基于索引的查找提高搜索性能。当将PrimaryKey值赋给DataTable时,会创建一个索引。当给DataTable创建DataView时,也会创建一个索引。下面是一些利用基于索引进行查找的技巧。
| ||||||||||||
DataView构造 | ||||||||||||
如果创建了DataView,并且修改了Sort、RowFilter或RowStateFilter属性,DataView就会为基础DataTable中的数据建立索引。创建DataView对象时,要使用DataView构造函数,它用Sort、RowFilter和RowStateFilter值作为构造函数参数(与基础DataTable一起)。结果是创建了一次索引。创建一个“空”DataView并随后设置Sort、RowFilter或RowStateFilter属性,会导致索引至少创建两次。 | ||||||||||||
分页 | ||||||||||||
ADO.NET可以显式控制从数据源中返回什么样的数据,以及在DataSet中本地缓存多少数据。对查询结果的分页没有唯一的答案,但下面有一些设计应用程序时应该考虑的技巧。
| ||||||||||||
注意:从查询中返回的结果页以降序显示。如果需要,应该重新排序。
| ||||||||||||
用架构填充DataSet | ||||||||||||
当用数据填充DataSet时,DataAdapter.Fill方法使用DataSet的现有架构,并使用从SelectCommand返回的数据填充它。如果在DataSet中没有表名与要被填充的表名相匹配,Fill方法就会创建一个表。默认情况下,Fill仅定义列和列类型。 | ||||||||||||
通过设置DataAdapter的MissingSchemaAction属性,可以重写Fill的默认行为。例如,要让Fill创建一个表架构,并且还包括主键信息、唯一约束、列属性、是否允许为空、最大列长度、只读列和自动增量的列,就要将DataAdapter.MissingSchemaAction指定为MissingSchemaAction.AddWithKey。或者,在调用DataAdapter.Fill前,可以调用DataAdapter.FillSchema来确保当填充DataSet时架构已到位。 | ||||||||||||
对FillSchema的调用会产生一个到服务器的额外行程,用于检索附加架构信息。为了获得最佳性能,需要在调用Fill之前指定DataSet的架构,或者设置DataAdapter的MissingSchemaAction。 | ||||||||||||
使用CommandBuilder的最佳实践 | ||||||||||||
假设SelectCommand执行单一表SELECT,CommandBuilder就会以DataAdapter的SelectCommand属性为基础自动生成DataAdapter的InsertCommand、UpdateCommand、和DeleteCommand属性。下面是为获得最佳性能而使用CommandBuilder的一些技巧。
| ||||||||||||
批处理SQL语句 | ||||||||||||
很多数据库支持将多条命令合并或批处理成一条单一命令执行。例如,SQL Server使您可以用分号“;”分隔命令。将多条命令合并成单一命令,能减少到服务器的行程数,并提高应用程序的性能。例如,可以将所有预定的删除在应用程序中本地存储起来,然后再发出一条批处理命令调用,从数据源删除它们。 | ||||||||||||
虽然这样做确实能提高性能,但是,当对DataSet中的数据更新进行管理时,可能会增加应用程序的复杂性。要保持简单,可能要在DataSet中为每个DataTable创建一个DataAdapter。 | ||||||||||||
用多个表填充DataSet | ||||||||||||
如果使用批处理SQL语句检索多个表并填充DataSet,第一个表用指定给Fill方法的表名命名。后面的表用指定给Fill方法的表名加上一个从1开始并且增量为1的数字命名。例如,如果运行下面的代码:
| ||||||||||||
来自Customers表的数据放在名为“Customers”的DataTable中。来自Orders表的数据放在名为“Customers1”的DataTable中。 | ||||||||||||
填充完DataSet之后,可以很容易地将“Customers1”表的TableName属性改为“Orders”。但是,后面的填充会导致“Customers”表被重新填充,而“Orders”表会被忽略,并创建另外一个“Customers1”表。为了对这种情况作出补救,创建一个DataTableMapping,将“Customers1”映射到“Orders”,并为其他后面的表创建其他的表映射。例如:
| ||||||||||||
使用DataReader | ||||||||||||
下面是一些使用DataReader获得最佳性能的技巧,同时还回答了一些关于使用DataReader的常见问题。
| ||||||||||||
另外一个显式关闭Connection的方法是将CommandBehavior.CloseConnection传递给ExecuteReader方法,以确保相关的连接在关闭DataReader时被关闭。如果从一个方法返回DataReader,而且不能控制DataReader或相关连接的关闭,则这样做特别有用。
| ||||||||||||
二进制大对象(BLOB) | ||||||||||||
用DataReader检索二进制大对象(BLOB)时,应该将CommandBehavior.SequentialAccess传递给ExecuteReader方法调用。因为DataReader的默认行为是每次Read都将整行加载到内存,又因为BLOB值可能非常大,所以结果可能由于单个BLOB而使大量内存被用光。SequentialAccess将DataReader的行为设置为只加载请求的数据。然后还可以使用GetBytes或GetChars控制每次加载多少数据。 | ||||||||||||
记住,使用SequentialAccess时,不能不按顺序访问DataReader返回的不同字段。也就是说,如果查询返回三列,其中第三列是BLOB,并且想访问前两列中的数据,就必须在访问BLOB数据之前先访问第一列的值,然后访问第二列的值。这是因为现在数据是顺序返回的,并且DataReader一旦读过该数据,该数据就不再可用。 | ||||||||||||
使用命令 | ||||||||||||
ADO.NET提供了几种命令执行的不同方法以及优化命令执行的不同选项。下面包括一些技巧,它们是关于选择最佳命令执行以及如何提高执行命令的性能。 | ||||||||||||
使用OleDbCommand的最佳实践 | ||||||||||||
不同.NET框架数据提供程序之间的命令执行被尽可能标准化了。但是,数据提供程序之间仍然存在差异。下面给出一些技巧,可微调用于OLE DB的.NET框架数据提供程序的命令执行。
| ||||||||||||
使用SqlCommand的最佳实践 | ||||||||||||
使用SqlCommand执行存储过程的快速提示:如果调用存储过程,将SqlCommand的CommandType属性指定为StoredProcedure的CommandType。这样通过将该命令显式标识为存储过程,就不需要在执行之前分析命令。 | ||||||||||||
使用Prepare方法 | ||||||||||||
对于重复作用于数据源的参数化命令,Command.Prepare方法能提高性能。Prepare指示数据源为多次调用优化指定的命令。要想有效利用Prepare,需要彻底理解数据源是如何响应Prepare调用的。对于一些数据源(例如SQL Server 2000),命令是隐式优化的,不必调用Prepare。对于其他(例如SQL Server 7.0)数据源,Prepare会比较有效。 | ||||||||||||
显式指定架构和元数据 | ||||||||||||
只要用户没有指定元数据信息,ADO.NET的许多对象就会推断元数据信息。下面是一些示例:
| ||||||||||||
但是,每次用到这些特性,都会有性能损失。建议将这些特性主要用于设计时和即席应用程序中。在可能的情况下,显式指定架构和元数据。其中包括在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参数都为空。
| ||||||||||||
将Null作为参数值传递 | ||||||||||||
对数据库的命令中,当将空值作为参数值发送时,不能使用null(Visual Basic .NET中为Nothing)。而需要使用DBNull.Value。例如:
| ||||||||||||
执行事务 | ||||||||||||
ADO.NET的事务模型已经更改。在ADO中,当调用StartTransaction时,调用之后的任何更新操作都被视为是事务的一部分。但是,在ADO.NET中,当调用Connection .BeginTransaction时,会返回一个Transaction对象,需要将它与Command的Transaction属性联系起来。这种设计可以在一个单一连接上执行多个根事务。如果未将Command.Transaction属性设置为一个针对相关的Connection而启动的Transaction,那么Command就会失败并引发异常。 | ||||||||||||
即将发布的.NET框架将使您可以在现有的分布式事务中手动登记。这对于对象池方案来说很理想;在该方案中,一个池对象打开一次连接,但是在多个独立的事务中都涉及到该对象。.NET框架1.0发行版中这一功能并不可用。 | ||||||||||||
使用连接 | ||||||||||||
高性能应用程序与使用中的数据源保持最短时间的连接,并且利用性能增强技术,例如连接池。下面的主题提供一些技巧,有助于在使用ADO.NET连接到数据源时获得更好的性能。 | ||||||||||||
连接池 | ||||||||||||
用于ODBC的SQL Server、OLE DB和.NET框架数据提供程序隐式缓冲连接。通过在连接字符串中指定不同的属性值,可以控制连接池的行为。 | ||||||||||||
用DataAdapter优化连接 | ||||||||||||
DataAdapter的Fill和Update方法在连接关闭的情况下自动打开为相关命令属性指定的连接。如果Fill或Update方法打开了连接,Fill或Update将在操作完成的时候关闭它。为了获得最佳性能,仅在需要时将与数据库的连接保持为打开。同时,减少打开和关闭多操作连接的次数。 | ||||||||||||
如果只执行单个的Fill或Update方法调用,建议允许Fill或Update方法隐式打开和关闭连接。如果对Fill和Update调用有很多,建议显式打开连接,调用Fill和Update,然后显式关闭连接。 | ||||||||||||
另外,当执行事务时,显式地在开始事务之前打开连接,并在提交之后关闭连接。例如:
| ||||||||||||
始终关闭Connection和DataReader | ||||||||||||
完成对Connection或DataReader对象的使用后,总是显式地关闭它们。尽管垃圾回收最终会清除对象并因此释放连接和其他托管资源,但垃圾回收仅在需要时执行。因此,确保任何宝贵的资源被显式释放仍然是您的责任。并且,没有显式关闭的Connections可能不会返回到池中。例如,一个超出作用范围却没有显式关闭的连接,只有当连接池大小达到最大并且连接仍然有效时,才会被返回到连接池中。 | ||||||||||||
注不要在类的Finalize方法中对Connection、DataReader或任何其他托管对象调用Close或Dispose。最后完成的时候,仅释放类自己直接拥有的非托管资源。如果类没有任何非托管资源,就不要在类定义中包含Finalize方法。 | ||||||||||||
在C#中使用“Using”语句 | ||||||||||||
对于C#程序员来说,确保始终关闭Connection和DataReader对象的一个方便的方法就是使用using语句。using语句在离开自己的作用范围时,会自动调用被“使用”的对象的Dispose。例如:
| ||||||||||||
Using语句不能用于Microsoft Visual Basic .NET。 | ||||||||||||
避免访问OleDbConnection.State属性 | ||||||||||||
如果连接已经打开,OleDbConnection.State属性会对DBPROP_CONNECTIONSTATUS属性的DATASOURCEINFO属性集执行本地OLE DB调用IDBProperties.GetProperties,这可能会导致对数据源的往返行程。也就是说,检查State属性的代价可能很高。所以仅在需要时检查State属性。如果需要经常检查该属性,监听OleDbConnection的StateChange事件可能会使应用程序的性能好一些。 | ||||||||||||
与XML集成 | ||||||||||||
ADO.NET在DataSet中提供了广泛的XML集成,并公开了SQL Server 2000及其更高版本提供的部分XML功能。还可以使用SQLXML 3.0广泛地访问SQL Server 2000及其更高版本中的XML功能。下面是使用XML和ADO.NET的技巧和信息。 | ||||||||||||
DataSet和XML | ||||||||||||
DataSet与XML紧密集成,并提供如下功能:
| ||||||||||||
注可以使用这种同步将XML功能(例如,XPath查询和XSLT转换)应用到DataSet中的数据,或者在保留原始XML保真度的前提下为XML文档中数据的全部或其中一个子集提供关系视图。 | ||||||||||||
架构推断 | ||||||||||||
从XML文件加载DataSet时,可以从XSD架构加载DataSet架构,或者在加载数据前预定义表和列。如果没有可用的XSD架构,而且不知道为XML文件的内容定义哪些表和列,就可以在XML文档结构的基础上对架构进行推断。 | ||||||||||||
架构推断作为迁移工具很有用,但应只限于设计阶段应用程序,这是由于推断处理有如下限制。
| ||||||||||||
用于XML查询的SQL Server | ||||||||||||
如果正从SQL Server 2000 FOR XML返回查询结果,可以让用于SQL Server的.NET框架数据提供程序使用SqlCommand.ExecuteXmlReader方法直接创建一个XmlReader。 | ||||||||||||
SQLXML托管类 | ||||||||||||
.NET框架中有一些类,公开用于SQL Server 2000的XML的功能。这些类可在Microsoft.Data.SqlXml命名空间中找到,它们添加了执行XPath查询和XML模板文件以及将XSLT转换应用到数据的能力。 | ||||||||||||
SQLXML托管类包含在用于Microsoft SQL Server 2000的XML (SQLXML 2.0)发行版中,可通过链接XML for Microsoft SQL Server 2000 Web Release 2 (SQLXML 2.0) | ||||||||||||
更多有用的技巧 | ||||||||||||
下面是一些编写ADO.NET代码时的通用技巧。 | ||||||||||||
避免自动增量值冲突 | ||||||||||||
就像大多数数据源一样,DataSet使您可标识那些添加新行时自动对其值进行递增的列。在DataSet中使用自动增量的列时,如果自动增量的列来自数据源,可避免添加到DataSet的行和添加到数据源的行之间本地编号冲突。 | ||||||||||||
例如,考虑一个表,它的主键列CustomerID是自动增量的。两个新的客户信息行添加到表中,并接收到自动增量的CustomerID值1和2。然后,只有第二个客户行被传递给DataAdapter的方法Update,新添加的行在数据源接收到一个自动增量的CustomerID值1,与DataSet中的值2不匹配。当DataAdapter用返回值填充表中第二行时,就会出现约束冲突,因为第一个客户行已经使用了CustomerID值1。 | ||||||||||||
要避免这种情况,建议在使用数据源上自动增量的列以及DataSet上自动增量的列时,将DataSet中的列创建为AutoIncrementStep值等于-1并且AutoIncrementSeed值等于0,另外,还要确保数据源生成的自动增量标识值从1开始,并且以正阶值递增。因此,DataSet为自动增量值生成负数,与数据源生成的正自动增量值不冲突。另外一个选择是使用GUID类型的列,而不是自动增量的列。生成GUID值的算法应该永远不会使数据源中生成的GUID值与DataSet中生成的GUID值一样。 | ||||||||||||
如果自动增量的列只是用作唯一值,而且没有任何意义,就考虑使用GUID代替自动增量的列。它们是唯一的,并且避免了使用自动增量的列所必需的额外工作。 | ||||||||||||
检查开放式并发冲突 | ||||||||||||
按照设计,由于DataSet是与数据源断开的,所以,当多个客户端在数据源上按照开放式并发模型更新数据时,需要确保应用程序避免冲突。 | ||||||||||||
在测试开放式并发冲突时有几项技术。一项技术涉及在表中包含时间戳列。另外一项技术是,验证一行中所有列的原始值是否仍然与通过在SQL语句中使用WHERE子句进行测试时在数据库中找到的值相匹配。 | ||||||||||||
多线程编程 | ||||||||||||
ADO.NET对性能、吞吐量和可伸缩性进行优化。因此,ADO.NET对象不锁定资源,并且必须只用于单线程。一个例外是DataSet,它对多个阅读器是线程安全的。但是,在写的时候需要将DataSet锁定。 | ||||||||||||
仅在需要的时候才用COM Interop访问ADO | ||||||||||||
ADO.NET的设计目的是成为许多应用程序的最佳解决方案。但是,有些应用程序需要只有使用ADO对象才有的功能,例如,ADO多维(ADOMD)。在这些情况下,应用程序可以用COM Interop访问ADO。注意使用COM Interop访问具有ADO的数据会导致性能降低。在设计应用程序时,首先在实现用COM Interop访问ADO的设计之前,先确定ADO.NET是否满足设计需求。 | ||||||||||||
关于可用数据提供程序的信息,以及每个数据提供程序最适合哪个数据源。
| ||||||||||||
注:ODBC数据提供程序包含在1.1以上版本的.NET framework中。包含的ODBC .NET数据提供程序的命名空间是System.Data.Odbc。
| ||||||||||||
注:用于Oracle的.NET数据提供程序包含在1.1以上版本的.NET framework中。
|
使用ADO.NET的最佳实践
最新推荐文章于 2021-09-13 12:55:28 发布