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

ado.net 引入的主要变化之一是用 datatable、dataset、dataadapter 和 datareader 对象的组合取代了 ado recordset 对象。datatable 表示单个表中行的集合，在这一方面类似于 recordset。dataset 表示 datatable 对象的集合，同时包括将各种表绑定在一起的关系和约束。实际上，dataset 是带有内置 xml 支持的、内存中的关系结构。

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

ado.net 依赖于 .net 数据提供程序的服务。这些提供程序提供对基础数据源的访问，并且包括四个主要对象（connection、command、datareader 和 dataadapter）。

目前，ado.net 随附了两类提供程序：bridge 提供程序和 native 提供程序。通过 bridge 提供程序（如那些为 ole db 和 odbc 提供的提供程序），可以使用为以前的数据访问技术设计的数据库。native 提供程序（如 sql server 和 oracle 提供程序）通常能够提供性能方面的改善，部分原因在于少了一个抽象层。

命名空间组织结构

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

在各自的关联命名空间内，每个提供程序都提供了对 connection、command、datareader 和 dataadapter 对象的实现。sqlclient 实现的前缀为“sql”，而 oledb 实现的前缀为“oledb”。例如，connection 对象的 sqlclient 实现是 sqlconnection，而 oledb 实现则为 oledbconnection。同样，dataadapter 对象的两个实现分别为 sqldataadapter 和 oledbdataadapter。

存储过程与直接 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 对象模型时）和调试。

管理数据库连接

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

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

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

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 .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 资源池。

监控连接池

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

使用 sql server 事件探查器监控连接池

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

管理安全性

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

使用 windows 身份验证

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

存储连接字符串

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

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

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

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

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

注 可以在连接字符串中将 persist security info 命名值设置为 false，以禁止通过 sqlconnection 或 oledbconnection 对象的 connectionstring 属性返回对安全敏感的细节（如密码）。

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

使用 xml 应用程序配置文件

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

<configuration> <appsettings>  <add key="dbconnstr"     value="server=(local);integrated security=sspi;database=northwind"/> </appsettings></configuration>

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

优点

缺点

可以使用 system.configuration.configurationsettings 类的静态 appsettings 属性来检索自定义应用程序设置。以下代码片段对此进行了说明，该代码片段采用了前面例举的名为 dbconnstr 的自定义密钥：

using system.configuration;private string getdbaseconnectionstring(){  return configurationsettings.appsettings["dbconnstr"];