.NET 数据访问体系结构指南

简介

如果您要为基于 .NET 的应用程序设计数据访问层，应该使用 Microsoft?ADO.NET 作为数据访问模型。ADO.NET 功能丰富，支持松耦合的多层 Web 应用程序和 Web 服务的数据访问要求。像其他功能丰富的对象模型一样，ADO.NET 提供了多种方法来解决特定问题。

《.NET 数据访问体系结构指南》提供的信息可帮助您选择最适合的数据访问方法。它通过描述一系列广泛的常见数据访问方案、提供性能提示以及推荐最佳实施策略来达到此目的。本指南还提供了对常见问题的解答，这些问题包括：哪里是存储数据库连接字符串的最佳场所？如何实现连接池？如何处理事务？如何实现分页以使用户能够在大量记录中滚动？

本指南集中讨论如何使用 ADO.NET 并通过 SQL Server .NET 数据提供程序（ADO.NET 随附的两个数据提供程序之一）来访问 Microsoft SQL?Server?2000。在适当的时候，本指南将明确指出您在使用 OLE DB .NET 数据提供程序来访问其他支持 OLE DB 的数据源时应该了解的差异。

有关使用本文中讨论的指南和最佳实施策略开发的数据访问组件的具体实现，请参阅 Data Access Application Block。Data Access Application Block 包含该实现的源代码，您可以在基于 .NET 的应用程序中直接使用这些代码。

《.NET 数据访问体系结构指南》分为以下几个部分：

本页内容

	ADO.NET 简介
	管理数据库连接
	错误处理
	性能
	通过防火墙进行连接
	处理 BLOB
	通过数据集执行数据库更新
	使用强类型数据集对象
	处理空数据字段
	事务处理
	数据分页
	附录

本文档的目标读者

本文档为需要生成基于 .NET 的应用程序的应用程序设计人员和企业开发人员提供指南。如果您负责设计和开发基于 .NET 的多层应用程序的数据层，请阅读本文档。

预备知识

要使用本指南来生成基于 .NET 的应用程序，您必须具有使用 ActiveX?Data Objects (ADO) 和/或 OLE DB 开发数据访问代码以及 SQL Server 方面的经验。您必须了解如何为 .NET 平台开发托管代码，并且必须了解 ADO.NET 数据访问模型引入的根本性的变化。有关 .NET 开发的详细信息，请参阅 http://msdn.microsoft.com/net。

新增功能

本文档已经进行了更新，以便包含有关执行数据集更新、使用类型化 DataSet 以及使用空数据字段的部分。

如正文中所指出的那样，本指南中的一些内容特别适用于 Microsoft Visual Studio?2003 开发系统和 .NET 框架 SDK 1.1 版。

下载《.NET 数据访问体系结构指南》

单击可从 MS.com 下载中心下载《.NET 数据访问体系结构指南》

ADO.NET 简介

ADO.NET 是基于 .NET 的应用程序的数据访问模型。可以使用它来访问关系数据库系统（如 SQL Server 2000、Oracle）和其他许多具有 OLE DB 或 ODBC 提供程序的数据源。在某种程度上，ADO.NET 代表 ADO 技术的最新进展。不过，ADO.NET 引入了一些重大变化和革新，旨在解决 Web 应用程序的松耦合特性以及在本质上互不关联的特性。有关 ADO 与 ADO.NET 的比较，请参阅 MSDN 文章“ADO.NET for the ADO Programmer”，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/adonetprogmsdn.asp。

ADO.NET 引入的主要变化之一是用 DataTable、DataSet、DataAdapter 和 DataReader 对象的组合取代了 ADO Recordset 对象。DataTable 表示单个表中行的集合，在这一方面类似于 Recordset。DataSet 表示 DataTable 对象的集合，同时包括将各种表绑定在一起的关系和约束。实际上，DataSet 是带有内置 XML 支持的、内存中的关系结构。

DataSet 的主要特性之一是它不了解可能用来填充它的基础数据源。它是一个不连续的、独立的实体，用于表示数据集合，并且可以通过多层应用程序的不同层在组件之间传递。它还可以作为 XML 数据流进行序列化，这使其非常适合于在不同种类的平台之间进行数据传输。ADO.NET 使用 DataAdapter 对象将数据传送到 DataSet 和基础数据源，或者从数据源传出。DataAdapter 对象还提供以前与 Recordset 关联的增强的批量更新功能。

图 1 显示了完整的 DataSet 对象模型。

图 1.1.DataSet 对象模型

.NET 数据提供程序

ADO.NET 依赖于 .NET 数据提供程序的服务。这些提供程序提供对基础数据源的访问，并且包括四个主要对象（Connection、Command、DataReader 和 DataAdapter）。

目前，ADO.NET 随附了两类提供程序：Bridge 提供程序和 Native 提供程序。通过 Bridge 提供程序（如那些为 OLE DB 和 ODBC 提供的提供程序），可以使用为以前的数据访问技术设计的数据库。Native 提供程序（如 SQL Server 和 Oracle 提供程序）通常能够提供性能方面的改善，部分原因在于少了一个抽象层。

其他目前正处于测试阶段的 .NET 数据提供程序包括：

有关不同数据提供程序的详细概述，请参阅《.NET 框架开发人员指南》中的“.NET 框架数据提供程序”，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconadonetproviders.asp。

命名空间组织结构

与各个 .NET 数据提供程序相关联的类型（类、结构、枚举等）位于其各自的命名空间中：

在各自的关联命名空间内，每个提供程序都提供了对 Connection、Command、DataReader 和 DataAdapter 对象的实现。SqlClient 实现的前缀为“Sql”，而 OleDb 实现的前缀为“OleDb”。例如，Connection 对象的 SqlClient 实现是 SqlConnection，而 OleDb 实现则为 OleDbConnection。同样，DataAdapter 对象的两个实现分别为 SqlDataAdapter 和 OleDbDataAdapter。

在本指南中，所用示例取自 SQL Server 对象模型。尽管此处未加说明，Oracle/OLEDB 和 ODBC 中提供了类似的功能。

一般编程

如果您可能要面向不同的数据源，并且需要将您的代码从一个数据源移至另一个数据源，请考虑编程以支持 System.Data 命名空间中的 IDbConnection、IDbCommand、IDataReader 和 IDbDataAdapter 接口。Connection、Command、DataReader 和 DataAdapter 对象的所有实现都必须支持这些接口。

有关实现 .NET 数据提供程序的详细信息，请参阅 http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconimplementingnetdataprovider.asp。

还应该注意，如果应用程序使用单对象模型来访问多个数据库，则 OLE DB 和 ODBC 桥接提供程序都可以使用。在此情况下，需要考虑与应用程序的性能需要相比，要求应用程序具有多大的灵活性，以及在何种程度上需要数据库特有的功能。

图 2 阐明了数据访问栈，并说明了 ADO.NET 与其他数据访问技术（包括 ADO 和 OLE DB）之间的关系。它还说明了 ADO.NET 模型内的两个托管提供程序和主要对象。

图 1.2.数据访问栈

有关 ADO 向 ADO.NET 的演变的详细信息，请参阅文章“Introducing ADO+:Data Access Services for the Microsoft .NET Framework”（MSDN Magazine，2000 年 11 月号），网址为：http://msdn.microsoft.com/msdnmag/issues/1100/adoplus/default.aspx。

存储过程与直接 SQL

本文档中显示的大多数代码片段使用 SqlCommand 对象来调用存储过程，以执行数据库操作。在某些情况下，您将不会看到 SqlCommand 对象，因为存储过程名被直接传递给 SqlDataAdapter 对象。在内部，这仍然会导致创建 SqlCommand 对象。

您应该使用存储过程而不是嵌入的 SQL 语句，原因如下：

SQL Server 联机文档强烈建议您不要使用“sp_”作为名称前缀来创建任何存储过程，因为此类名称已经被指定给系统存储过程。SQL Server 始终按以下顺序来查找以 sp_ 开头的存储过程：

属性与构造函数参数

可以通过构造函数参数来设置 ADO.NET 对象的特定属性值，也可以直接设置属性值。例如，下面的代码片段在功能上是等效的。

// Use constructor arguments to configure command objectSqlCommand cmd = new SqlCommand( "SELECT * FROM PRODUCTS", conn );// The above line is functionally equivalent to the following// three lines which set properties explicitlysqlCommand cmd = new SqlCommand();cmd.Connection = conn;cmd.CommandText = "SELECT * FROM PRODUCTS";

从性能角度看，这两种方法之间的差异是微不足道的，因为针对 .NET 对象设置和获取属性要比针对 COM 对象执行类似操作更为高效。

选择哪种方法取决于个人喜好和编码风格。不过，对属性进行明确设置确实能够使代码更易理解（尤其是当您不熟悉 ADO.NET 对象模型时）和调试。

注 过去，Microsoft Visual Basic? 开发系统的开发人员被告诫避免使用“Dim x As New…”构造来创建对象。在 COM 领域里，上述代码会导致 COM 对象创建过程出现短路现象，从而带来一些微小和重大的错误。然而，在 .NET 领域里，这不再是一个问题。

返回页首

管理数据库连接

数据库连接代表一种关键的、昂贵的和有限的资源，尤其是在多层 Web 应用程序中。正确地管理连接是十分必要的，因为您采取的方法可能显著影响应用程序的总体可伸缩性。同时，还要认真考虑在何处存储连接字符串。需要使用可配置的且安全的位置。

在管理数据库连接和连接字符串时，应该努力做到：

本节讨论连接池，并且帮助您选择适当的连接池策略。本节还将考虑应该如何管理、存储和操纵数据库连接字符串。最后，本节将给出两种编码模式，可用来帮助确保连接被可靠地关闭，并被返回到连接池。

使用连接池

通过数据库连接池，应用程序可以重用池中现有的连接，而不必反复与数据库建立新的连接。该技术可显著提高应用程序的可伸缩性，因为有限数量的数据库连接可以为数量大得多的客户端提供服务。同时，由于可以节省建立新连接所需的大量时间，该技术还能够改善性能。

像 ODBC 和 OLE DB 这样的数据访问技术提供了多种形式的连接池，可以在不同程度上进行配置。这两种方法对于数据库客户端应用程序而言在很大程度上是透明的。OLE DB 连接池经常被称为会话或资源池。

有关 Microsoft Data Access Components (MDAC) 内部的池机制的一般性讨论，请参阅“Pooling in the Microsoft Data Access Components”，网址为 http://msdn.microsoft.com/library/en-us/dnmdac/html/pooling2.asp。

ADO.NET 数据提供程序提供了透明的连接池，这些连接池的确切技术细节对于各个提供程序而言是不同的。本节针对下列提供程序来讨论连接池：

SQL Server .NET 数据提供程序的池机制

如果您使用的是 SQL Server .NET 数据提供程序，请使用该提供程序提供的连接池支持。这是一种由该提供程序在内部实现的支持事务处理并且非常高效的机制，它存在于托管代码中。池是以每个应用程序的域为基础创建的，并且在应用程序域卸载之前不会销毁。

可以透明地使用这种形式的连接池，但应该知道池的管理方式以及可用来微调连接池的各种配置选项。

在许多情况下，对于您的应用程序而言，SQL Server .NET 数据提供程序的默认连接池设置可能已经足够了。在开发和测试基于 .NET 的应用程序的过程中，建议您对规划通信模式进行模拟，以确定是否需要修改连接池大小。

需要生成可伸缩的高性能应用程序的开发人员应该最大限度地减少使用连接的时间，只在检索或更新数据时才使连接保持打开状态。连接关闭时，将被返回到连接池，并可供重用。在此情况下，到数据库的实际连接不会被切断；不过，如果连接池被禁用，则到数据库的实际连接将被关闭。

开发人员应该十分小心，不要依赖垃圾回收器来释放连接，因为当引用离开作用范围时，连接未必能够关闭。这是连接泄漏的一种常见根源，当请求新连接时，这会导致连接异常。

配置 SQL Server .NET 数据提供程序连接池

可以使用一组名称-值对（通过连接字符串提供）来配置连接池。例如，可以配置是否启用连接池（默认情况下启用）、池的最大容量和最小容量，以及要打开连接的排队请求可以阻塞的时间长度。下面是一个示例连接字符串，用于配置池的最大容量和最小容量。

"Server=(local); Integrated Security=SSPI; Database=Northwind; Max Pool Size=75; Min Pool Size=5"

打开连接并创建池以后，会将多个连接添加到池中，以便将连接数量提高到所配置的最小数量。随后，可以继续向该池中添加连接，直至达到所配置的最大池数量。当达到最大数量时，要打开连接的新请求将排队等待一段可配置的时间。

选择池大小

对于管理成千上万个客户端的并发请求的大规模系统而言，能够建立最大值阈值是非常重要的。您需要监控连接池和应用程序的性能，以便确定系统的最佳池大小。最佳大小还取决于用来运行 SQL Server 的硬件。

在部署过程中，您可能希望减小默认的最大池大小（目前为 100）以帮助查找连接泄漏。

如果您设立最小池大小，将会产生一点性能开销，因为在开始时对池进行填充以使其达到该尺寸，尽管头几个进行连接的客户端会因此受益。注意，创建新连接的过程是按顺序执行的，这意味着在最初填充池时，服务器不会被同时到来的大量请求所淹没。

有关监控连接池的详细信息，请参阅本文档中的监控连接池一节。有关连接池连接字符串关键字的完整列表，请参阅《.NET 框架开发人员指南》中的“Connection Pooling for the .NET Framework Data Provider for SQL Server”一节，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconconnectionpoolingforsqlservernetdataprovider.asp。

更多信息

当使用 SQL Server .NET 数据提供程序连接池时，请注意以下几个方面：

SqlConnection conn = new SqlConnection(         "Integrated Security=SSPI;Database=Northwind");conn.Open(); // Pool A is createdSqlConmection conn = new SqlConnection(         "Integrated Security=SSPI ; Database=Northwind");conn.Open(); // Pool B is created (extra spaces in string)

OLE DB .NET 数据提供程序的池机制

OLE DB .NET 数据提供程序通过使用基础 OLE DB 资源池来池化连接。有多个用于配置资源池的选择：

为避免出现与注册表相关的部署问题，请不要使用注册表来配置 OLE DB 资源池。

有关 OLE DB 资源池的详细信息，请参阅《OLE DB 程序员参考》第 19 章“OLE DB Services”中的“Resource Pooling”，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledb/htm/olprcore_chapter19.asp。

使用池对象管理连接池

作为 Windows DNA 开发人员，鼓励您禁用 OLE DB 资源池和/或 ODBC 连接池，并使用 COM+ 对象池作为池化数据库连接的技术。这有两个主要原因：

然而，因为 SQL Server .NET 数据提供程序在内部使用池机制，所以您不再需要开发自己的对象池机制（在使用该提供程序时）。因此，您可以避免执行与手动事务登记相关联的复杂任务。

如果您使用的是 OLE DB .NET 数据提供程序，您可能需要考虑使用 COM+ 对象池，以便充分利用卓越的配置和改善的性能。如果您为此目的开发池对象，则必须禁用 OLE DB 资源池和自动事务登记（例如，通过在连接字符串中包含 "OLE DB Services=-4"）。您必须在自己的池对象实现中处理事务登记。

监控连接池

要对应用程序使用连接池的情况进行监控，可以使用 SQL Server 随附的事件探查器工具，或者使用 Microsoft Windows? 2000 操作系统随附的性能监视器工具。

使用 SQL Server 事件探查器监控连接池

使用性能监视器监控连接池

管理安全性

尽管数据库连接池提高了应用程序的总体可伸缩性，但这意味着您不再能够在数据库级别管理安全性。这是因为，要支持连接池，连接字符串必须完全相同。如果您需要跟踪每个用户的数据库操作，请考虑添加一个参数，以便能够传递用户标识并在数据库中手动记录用户操作。您需要将该参数添加到每个操作中。

使用 Windows 身份验证

在连接到 SQL Server 时，应该使用 Windows 身份验证，因为它提供了许多好处：

更多信息

在使用 Windows 身份验证来访问 SQL Server 时，请遵循以下指导原则：

有关开发安全的 ASP.NET 和 Web 应用程序的一般性指导，请参阅下面的 Microsoft patterns & practices 指南：

存储连接字符串

要存储数据库连接字符串，可以有多种选择，这些选择具有不同级别的灵活性和安全性。尽管在源代码中对连接字符串进行硬编码可提供最佳性能，但文件系统缓存可确保在外部将该字符串存储到文件系统中所带来的性能下降是微不足道的。几乎在所有情况下，人们都首选外部连接字符串所提供的额外的灵活性（它支持管理员配置）。

当您选择连接字符串存储方法时，需要注意的两个最重要的事项是安全性和配置简易性，然后紧跟着的是性能。

可以选择下列位置来存储数据库连接字符串：

通过使用 Windows 身份验证来访问 SQL Server，可以避免将用户名和密码存储在连接字符串中。如果您的安全要求需要采取更严格的措施，请考虑以加密格式存储连接字符串。

对于 ASP.NET Web 应用程序而言，在 Web.config 文件内以加密格式存储连接字符串，代表着一种安全的、可配置的解决方案。

注 可以在连接字符串中将 Persist Security Info 命名值设置为 false，以禁止通过 SqlConnection 或 OleDbConnection 对象的 ConnectionString 属性返回对安全敏感的细节（如密码）。

下面几小节讨论了如何使用各种选择来存储连接字符串，并介绍了各种方法的相对优点和缺点。这些内容有助于您根据自己特定的应用程序方案做出明智的选择。

注 通过“配置应用程序管理”块，可以管理从数据库连接到复杂层次结构数据的各种配置设置。有关详细信息，请参阅 http://msdn.microsoft.com/practices。

使用 XML 应用程序配置文件

可以使用 <appSettings> 元素在应用程序配置文件的自定义设置节中存储数据库连接字符串。该元素支持任意的密钥-值对，如以下代码片段所示：

<configuration> <appSettings>  <add key="DBConnStr"     value="server=(local);Integrated Security=SSPI;database=northwind"/> </appSettings></configuration>

注 <appSettings> 元素出现在 <configuration> 元素下面，并且不是紧跟在 <system.web> 的后面。

优点

缺点

更多信息

using System.Configuration;private string GetDBaseConnectionString(){  return ConfigurationSettings.AppSettings["DBConnStr"];}

使用 UDL 文件

OLE DB .NET 数据提供程序在其连接字符串中支持通用数据链接 (UDL) 文件名。您可以通过使用 OleDbConnection 对象的构建参数来传递连接字符串，或者通过使用该对象的 ConnectionString 属性来设置连接字符串。

注 SQL Server .NET 数据提供程序在其连接字符串中不支持 UDL 文件。因此，只有在您使用 OLE DB .NET 数据提供程序时，才可使用该方法。

对于 OLE DB 提供程序，要通过连接字符串引用 UDL 文件，请使用“File Name=name.udl”。

优点

缺点

更多信息

使用 Windows 注册表

您还可以在 Windows 注册表中使用自定义键来存储连接字符串，尽管由于部署问题不鼓励这样做。

优点

缺点

部署。必须与应用程序一起部署相关注册表设置，这在一定程度上抵消了 xcopy 部署的优点。

使用自定义文件

可使用自定义文件来存储连接字符串。然而，该技术没有任何优点，建议不要使用该技术。

优点

缺点

使用构建参数和 COM+ 目录

可以在 COM+ 目录中存储数据库连接字符串，并通过对象构建字符串将其自动传递给您的对象。COM+ 将在实例化该对象后立即调用该对象的 Construct 方法，同时提供所配置的构建字符串。

注 该方法仅对服务组件有效。仅当您的托管组件使用其他服务（如分布式事务处理支持或对象池）时，才应考虑该方法。

优点

缺点

更多信息

连接使用模式

无论您使用哪种 .NET 数据提供程序，您都必须始终遵循下列原则：

要保证在方法返回之前关闭连接，请考虑使用下面的两个代码示例中阐明的方法之一。第一个方法使用 finally 块。第二个方法使用 C# using 语句，它确保调用对象的 Dispose 方法。

以下代码确保 finally 块关闭连接。注意，该方法对 Visual Basic .NET 和 C# 都有效，因为 Visual Basic .NET 支持结构化异常处理。

public void DoSomeWork(){  SqlConnection conn = new SqlConnection(connectionString);  SqlCommand cmd = new SqlCommand("CommandProc", conn );  cmd.CommandType = CommandType.StoredProcedure;  try  {    conn.Open();    cmd.ExecuteNonQuery();  }  catch (Exception e)  {    // Handle and log error  }  finally  {    conn.Close();  }}  

以下代码显示了一个备选方法，该方法使用了 C# using 语句。注意，Visual Basic .NET 不提供 using 语句或任何等效功能。

public void DoSomeWork(){  // using guarantees that Dispose is called on conn, which will  // close the connection.  using (SqlConnection conn = new SqlConnection(connectionString))  {    SqlCommand cmd = new SqlCommand("CommandProc", conn);    fcmd.CommandType = CommandType.StoredProcedure;    conn.Open();    cmd.ExecuteQuery();  }}  

您还可以将该方法应用于其他必须关闭才能使用当前连接执行其他任何任务的对象，例如 SqlDataReader 或 OleDbDataReader。

返回页首

错误处理

ADO.NET 错误是通过 .NET 框架所固有的基础结构化异常处理支持来产生和处理的。因此，在数据访问代码内部处理错误的方法与在应用程序的其他地方一样。可以通过标准的 .NET 异常处理语法和技术来检测和处理异常。

本节向您说明如何开发健壮的数据访问代码，并解释如何处理数据访问错误。同时，本节还提供了与 SQL Server .NET 数据提供程序相关的具体异常处理指导。

.NET 异常

.NET 数据提供程序将数据库特有的错误状况转换为标准异常类型，供您在自己的数据访问代码中进行处理。数据库特有的错误细节是通过相关异常对象的属性提供给您的。

所有 .NET 异常类型归根结底都是从 System 命名空间中的 Exception 类派生出来的。.NET 数据提供程序引发提供程序特有的异常类型。例如，每当 SQL Server 返回错误状况时，SQL Server .NET 数据提供程序都会引发 SqlException 对象。类似地，OLE DB .NET 数据提供程序引发 OleDbException 类型的异常，它含有基础 OLE DB 提供程序所公开的细节。

图 3 显示了 .NET 数据提供程序异常层次。注意，OleDbException 类是从 ExternalException（它是所有 COM Interop 异常的基类）派生的。该对象的 ErrorCode 属性存储了由 OLE DB 产生的 COM HRESULT。

图 1.3..NET 数据提供程序异常层次

捕获和处理 .NET 异常

要处理数据访问异常状况，请将数据访问代码放在 try 块内部，并使用 catch 块通过适当的筛选器来捕获产生的任何异常。例如，当使用 SQL Server .NET 数据提供程序来编写数据访问代码时，应该捕获 SqlException 类型的异常，如以下代码所示：

try{  // Data access code}catch (SqlException sqlex) // more specific{}catch (Exception ex) // less specific{}  

如果您提供多个具有不同筛选条件的 catch 语句，请记住将这些语句按其类型的特殊程度从高到低排序。这样，对于任何给定的异常类型，都会执行最特殊类型的 catch 块。

该 SqlException 类公开了含有异常状况细节的属性。这些属性包括：

以下代码片段阐明了如何使用 SQL Server .NET 数据提供程序来处理 SQL Server 错误状况：

using System.Data;using System.Data.SqlClient;using System.Diagnostics;// Method exposed by a Data Access Layer (DAL) Componentpublic string GetProductName( int ProductID ){  SqlConnection conn = null;  // Enclose all data access code within a try block  try  {    conn = new SqlConnection(        "server=(local);Integrated Security=SSPI;database=northwind");    conn.Open();    SqlCommand cmd = new SqlCommand("LookupProductName", conn );    cmd.CommandType = CommandType.StoredProcedure;    cmd.Parameters.Add("@ProductID", ProductID );    SqlParameter paramPN =          cmd.Parameters.Add("@ProductName", SqlDbType.VarChar, 40 );    paramPN.Direction = ParameterDirection.Output;    cmd.ExecuteNonQuery();    // The finally code is executed before the method returns    return paramPN.Value.ToString();    }  catch (SqlException sqlex)  {    // Handle data access exception condition    // Log specific exception details    LogException(sqlex);    // Wrap the current exception in a more relevant    // outer exception and re-throw the new exception    throw new DALException(                  "Unknown ProductID: " + ProductID.ToString(), sqlex );  }  catch (Exception ex)  {    // Handle generic exception condition . . .    throw ex;  }  finally  {    if(conn != null) conn.Close(); // Ensures connection is closed  }}// Helper routine that logs SqlException details to the // Application event logprivate void LogException( SqlException sqlex ){  EventLog el = new EventLog();  el.Source = "CustomAppLog";  string strMessage;  strMessage = "Exception Number : " + sqlex.Number +                "(" + sqlex.Message + ") has occurred";  el.WriteEntry( strMessage );  foreach (SqlError sqle in sqlex.Errors)  {    strMessage = "Message: " + sqle.Message +                 " Number: " + sqle.Number +                 " Procedure: " + sqle.Procedure +                 " Server: " + sqle.Server +                 " Source: " + sqle.Source +                 " State: " + sqle.State +                 " Severity: " + sqle.Class +                 " LineNumber: " + sqle.LineNumber;    el.WriteEntry( strMessage );  }}

在 SqlException catch 块内部，代码首先使用 LogException 辅助函数记录异常细节。该函数使用 foreach 语句来枚举 Errors 集合内部的特定于提供程序的细节，并将错误细节记录到错误日志中。catch 块中的代码随后将 SQL Server 特有的异常包装在 DALException 类型的异常内部，后者对于 GetProductName 方法的调用方更有意义。异常处理程序使用 throw 关键字将该异常传播回调用方。

更多信息

从存储过程中产生错误

Transact-SQL (T-SQL) 提供了一个 RAISERROR函数（请注意拼写），可用来产生自定义错误并将其返回到客户端。对于 ADO.NET 客户端，SQL Server .NET 数据提供程序会截获这些数据库错误，并将其转换为 SqlError 对象。

使用 RAISERROR 函数的最简单方法是将消息正文包含为第一个参数，然后指定严重度和状态参数，如以下代码片段所示。

RAISERROR( 'Unknown Product ID: %s', 16, 1, @ProductID )

在该示例中，使用了一个替代参数将当前产品 ID 作为错误消息正文的一部分返回。第二个参数是消息严重度，第三个参数是消息状态。

更多信息

RAISERROR( 50001, 16, 1, @ProductID )

适当地使用严重度级别

请认真选择错误严重度级别，并注意各个级别的影响。错误严重度级别的范围为 0 到 25，用于表示 SQL Server 2000 已经遇到的问题类型。在客户端代码中，可以通过检查 SqlError 对象的 Class 属性获得错误的严重度，该对象位于 SqlException 类的 Errors 集合中。表 1 指出了各种严重度级别的影响和含义。

表 1. 错误严重度级别 — 影响和含义

控制自动事务处理

对于所遇到的任何严重度超过 10 的错误，SQL Server .NET 数据提供程序都会引发 SqlException。当自动 (COM+) 事务处理中的某个组件检测到 SqlException 时，该组件必须确保它赞成中止该事务处理。这可能是也可能不是自动过程，具体取决于是否用 AutoComplete 属性对该方法进行了标记。

有关在自动事务处理的上下文中处理 SqlException 的详细信息，请参阅本文档中的确定事务处理结果一节。

检索指示性消息

严重度级别 10 及更低级别用于表示指示性消息，并且不会导致引发 SqlException。

检索指示性消息：

public delegate void SqlInfoMessageEventHandler( object sender,                                                      SqlInfoMessageEventArgs e );

消息数据可通过传递给事件处理程序的 SqlInfoMessageEventArgs 对象获得。该对象公开了一个 Errors 属性，该属性包含一组 SqlError 对象 — 每条指示性消息对应一个对象。以下代码片段阐明了如何注册一个用于记录指示性消息的事件处理程序。

public string GetProductName( int ProductID ){  SqlConnection conn = null;  try  {    conn = new SqlConnection(        "server=(local);Integrated Security=SSPI;database=northwind");    // Register a message event handler    conn.InfoMessage += new SqlInfoMessageEventHandler( MessageEventHandler );    conn.Open();    // Setup command object and execute it    . . .  }  catch (SqlException sqlex)  {    // log and handle exception    . . .  }  finally  {    if(conn != null) conn.Close();  }}// message event handlervoid MessageEventHandler( object sender, SqlInfoMessageEventArgs e ){  foreach( SqlError sqle in e.Errors )  {    // Log SqlError properties    . . .  }}

返回页首

性能

本节介绍一些常见的数据访问方案，对于每种方案，都提供了就 ADO.NET 数据访问代码而言性能最高、可伸缩性最强的解决方案的有关详细信息。在适当的地方，对性能、功能和开发工作进行了比较。本节考虑了下列功能方案：

检索多行

在该方案中，您希望检索一组表格形式的数据，并对检索到的行进行迭代以执行操作。例如，您可能希望检索一组数据，以不连续的方式处理这些数据，并将其作为 XML 文档传递给客户端应用程序（可能是通过 Web 服务传递）。或者，您还可能希望以 HTML 表的形式显示这些数据。

要帮助确定最适当的数据访问方法，请考虑您是需要（不连续的）DataSet 对象所提供的额外的灵活性，还是需要 SqlDataReader 对象（它非常适合于企业对用户 (B2C) Web 应用程序中的数据展示）所提供的原始性能。图 4 显示了这两种基本方案。

注 用于在内部填充 DataSet 的 SqlDataAdapter 使用 SqlDataReader 来访问数据。

图 1.4.多行数据访问方案

比较几种选择

当从数据源中检索多个行时，您具有下列选择：

选择 SqlDataReader 还是 DataSet/DataTable，从根本上说是一个注重性能还是注重功能的问题。SqlDataReader 可提供最佳性能；DataSet 可提供额外的功能和灵活性。

数据绑定

上述所有三个对象都可以充当数据绑定控件的数据源，尽管 DataSet 和 DataTable 可以充当比 SqlDataReader 更多种控件的数据源。这是因为 DataSet 和 DataTable 实现了 IListSource（产生 IList），而 SqlDataReader 则实现了 IEnumerable。一些支持数据绑定的 WinForm 控件需要实现了 IList 的数据源。

这一差异的原因在于为其设计各种对象类型的方案的类型。DataSet（它包含 DataTable）是一种丰富的、不连续的结构，同时适用于 Web 和桌面 (WinForm) 这两种方案。另一方面，数据读取器对需要执行优化的只进数据访问的 Web 应用程序进行了优化。

请检查您希望绑定到的特定控件类型的数据源要求。

在应用程序层之间传递数据

DataSet 为可以根据需要作为 XML 进行操作的数据提供了关系视图，并且使您可以在应用程序层和组件之间传递不连续的缓存数据副本。然而，SqlDataReader 提供了最佳性能，因为它避免了与 DataSet 的创建关联的性能和内存开销。请记住，DataSet 对象的创建可导致多个子对象（包括 DataTable、DataRow 和 DataColumn 对象）以及用作这些子对象的容器的集合对象的创建。

使用数据集

在下列情况下，请使用由 SqlDataAdapter 对象填充的 DataSet：

更多信息

如果您使用 SqlDataAdapter 来生成 DataSet 或 DataTable，请注意下列事项：

使用 SqlDataReader

在下列情况下，请使用通过调用 SqlCommand 对象的 ExecuteReader 方法得到的 SqlDataReader：

更多信息

如果您使用 SqlDataReader，请注意以下事项：

使用 XmlReader

在以下情况下，请使用通过调用 SqlCommand 对象的 ExecuteXmlReader 方法得到的 XmlReader：

更多信息

如果您使用 XmlReader，请注意以下事项：

检索单个行

在该方案中，您希望从数据源中检索包含指定列集的单行数据。例如，您有一个客户 ID 并希望查找相关的客户详细信息，或者您有一个产品 ID 并希望检索产品信息。

比较几种选择

如果您希望使用从数据源中检索到的单行执行数据绑定，可以使用 SqlDataAdapter，以与前面讨论的“多行检索和迭代”方案中介绍的相同方式来填充 DataSet 或 DataTable。然而，除非您特别需要 DataSet/DataTable 功能，否则应该避免创建这些对象。

如果您需要检索单个行，请使用下列选择之一：

这两个选择都可以避免由于在服务器上创建结果集和在客户端上创建 DataSet 而带来的不必要的开销。各个方法的相对性能取决于压力级别以及是否启用了数据库连接池。当启用了数据库连接池时，性能测试表明，存储过程方法在高压力条件（同时存在 200 个以上的连接）下的性能比 SqlDataReader 方法高将近 30%。

使用存储过程输出参数

当您希望从已经启用连接池的多层 Web 应用程序中检索单个行时，请使用存储过程输出参数。

更多信息

有关说明如何使用存储过程输出参数的代码示例，请参阅附录中的如何使用存储过程输出参数来检索单个行。

使用 SqlDataReader

在以下情况下，请使用 SqlDataReader：

更多信息

如果您使用 SqlDataReader，请注意以下事项：

检索单个项

在该方案中，您希望检索单个数据项。例如，您可能希望查找单个产品名（给定了产品 ID）或单个客户信用等级（给定了客户名称）。在此类方案中，您通常不希望在检索单个项时产生 DataSet 的开销，甚至不希望产生 DataTable 的开销。

您可能还希望简单地检查一下数据库中是否存在特定行。例如，当新用户在网站上注册时，您需要检查选择的用户名是否已存在。这是单项查找的特殊情况，但在此情况下，简单的 Boolean 类型返回值就足够了。

比较几种选择

当您从数据源中检索单个数据项时，请考虑下列选择：

ExecuteScalar 方法直接返回数据项，因为它专用于只返回单个值的查询。它所需要的代码比存储过程输出参数和 SqlDataReader 方法需要的代码都要少。

从性能角度而言，应该使用存储过程输出或返回参数，因为测试表明，存储过程方法在低压力条件和高压力条件下（从同时存在的浏览器连接少于 100 个到同时存在 200 个浏览器连接）都能够提供一致的性能。

更多信息

在检索单个项时，请注意以下事项：

返回页首

通过防火墙进行连接

您将经常需要配置 Internet 应用程序以通过防火墙连接到 SQL Server。例如，许多 Web 应用程序及其防火墙的关键体系结构组件是外围网络（也称为 DMZ，即非管制区），它用于将前端 Web 服务器与内部网络隔离。

通过防火墙连接到 SQL Server 时，要求对防火墙、客户端和服务器进行特殊的配置。SQL Server 提供了客户端网络实用工具和服务器网络实用工具程序来帮助进行配置。

选择网络库

在通过防火墙进行连接时，可使用 SQL Server TCP/IP 网络库来简化配置。这是 SQL Server 2000 安装的默认配置。如果您使用的是较低版本的 SQL Server，请确保已经分别通过使用客户端网络实用工具和服务器网络实用工具，在客户端和服务器上将 TCP/IP 配置为默认网络库。

除了配置方面的好处以外，使用 TCP/IP 库结果还意味着您可以：

您必须将客户端计算机和服务器计算机配置为使用 TCP/IP。因为大多数防火墙都对允许通信的端口集进行限制，所以您还必须对 SQL Server 使用的端口号给予认真的考虑。

配置服务器

SQL Server 的默认实例在端口 1433 上侦听。同时，还使用了 UDP 端口 1434，以使 SQL 客户端能够定位其网络中的其他 SQL 服务器。然而，SQL?Server?2000 的命名实例在首次启动时动态分配端口号。网络管理员不希望在防火墙上打开一系列端口号；因此，在使用带防火墙的 SQL Server 命名实例时，请使用服务器网络实用工具来配置该实例，以使其在特定端口号上侦听。然后，您的管理员可以配置防火墙，以允许通信到达该服务器实例正在侦听的特定 IP 地址和端口号。

注 客户端网络库使用的源端口是在范围 1024 - 5000 中动态分配的。对于 TCP/IP 客户端应用程序，这是标准做法，但这意味着您的防火墙必须允许来自该范围内任意端口的通信。有关 SQL Server 使用的端口的详细信息，请参阅 Microsoft 知识库文章 287932“INF:TCP Ports Needed for Communication to SQL Server Through a Firewall”。

动态发现命名实例

如果您更改 SQL Server 所侦听的默认端口号，请配置客户端以连接到此端口。有关详细信息，请参阅本文档中的配置客户端一节。

在为 SQL Server 2000 的默认实例更改端口号后，如果未能修改客户端，将导致连接错误。如果有多个 SQL Server 实例，最新版本的 MDAC 数据访问栈 (2.6) 将使用动态发现，并且使用用户数据文报协议 (UDP) 协商（通过 UDP 端口 1434）来查找命名实例。尽管这可能在开发环境中有效，但却不太可能在实际应用环境中起作用，因为防火墙通常会阻塞 UDP 协商通信。

要避免这一问题，请始终配置客户端以连接到已配置的目标端口号。

配置客户端

应该配置客户端以使用 TCP/IP 网络库连接到 SQL?Server，并且应确保客户端库使用正确的目标端口号。

使用 TCP/IP 网络库

您可以使用 SQL Server 客户端网络实用工具来配置客户端。在某些安装中，客户端（例如，您的 Web 服务器）上可能尚未安装该实用工具。在此情况下，您可以执行下列操作之一：

指定端口

如果您的 SQL Server 实例被配置为在除默认的 1433 以外的端口上侦听，可以通过以下方法指定要连接到端口号：

"Data Source=ServerName, PortNumber"

分布式事务处理

如果您已经开发了使用 COM+ 分布式事务处理以及 Microsoft 分布式事务处理协调器 (DTC) 的服务的服务组件，您可能还需要配置您的防火墙以允许 DTC 通信在独立的 DTC 实例之间流动，以及在 DTC 和资源管理器（如 SQL Server）之间流动。

有关为 DTC 打开端口的详细信息，请参阅 INFO:Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall。

返回页首

处理 BLOB

现在，许多应用程序除了处理较为传统的字符和数值数据以外，还需要处理诸如图形和声音之类的数据格式，甚至需要处理更为复杂的数据格式，如视频。存在许多不同类型的图形、声音和视频格式。不过，从存储角度而言，它们都可以视为二进制数据块，通常称为二进制大对象，即 BLOB。

SQL Server 提供了 binary、varbinary 和 image 数据类型来存储 BLOB。尽管具有现在的名称，BLOB 数据还可以指基于文本的数据。例如，您可能希望存储可以与特定行关联的任意长的注释字段。为此，SQL Server 提供了 ntext 和 text 数据类型。

通常，对于小于 8 KB 的二进制数据，请使用 varbinary 数据类型。对于超过此大小的二进制数据，请使用 image。表 2 介绍了每个数据类型的主要功能。

表 2. 数据类型功能