.NET 数据访问架构指南

　　概述：本文提供了在多层.NET应用程序中实施基于ADO.NET的数据访问层的指导原则。其重点是一组通用数据访问任务和方案，并指导你选择最合适的途径和技术.
　　目录
　　
　　ADO.NET简介
　　管理数据库链接
　　错误处理
　　性能
　　通过防火墙建立链接
　　处理 BLOBs
　　事务处理
　　数据分页
　　
　　
　　简介
　　
　　如果你在为.NET应用程序设计数据访问层，那么就应该把 Microsoft ADO.NET用作数据访问模型。ADO.NET扩展丰富，并且支持结合松散的数据访问需求、多层Web应用程序及Web服务。通常，它利用许多扩展丰富的对象模型， ADO.NET提供了多种方法用于解决一个特定问题。
　　
　　本文将指导你选择最合适的数据访问方法，其做法是详细列出大范围的通用数据访问方案，提供运用技巧，并且建议最优实践。本文还回答了其它经常问到的问题：何处最适合存放数据库链接字符串？应如何实现链接存储池？如何处理事务？如何实现分页以允许用户在许多记录中滚动？
　　
　　注意本文的重点是ADO.NET的使用：利用SQL Server .NETData Provider--随ADO.NET一起提供的两个供应器之一--访问Microsoft SQL Server 2000。本文在合适的地方，将突出显示在你使用OLE DB .NET数据供应器访问其它OLE DB敏感数据源时需要注意的所有差别。
　　
　　对于利用本文所讨论的指导原则和最优实践所开发的数据访问组件的具体实现，见(Data Access Application Block)数据访问应用程序块。注意，本实现的源代码是可以获得的，并且能直接用于你的.NET应用程序中。
　　
　　谁应当阅读本文？
　　
　　本文为希望构建.NET应用程序的应用程序设计师和企业开发人员提供了指导原则。如果你负责设计并开发多层.NET应用程序的数据层，那么请阅读本文。
　　
　　你首先需要知道什么？
　　
　　要利用本指南构建.NET应用程序，你必须有利用ActiveX数据对象(ADO)和/或 OLE DB开发数据访问代码的实际经验，及SQL Server经验。你也必须明白如何为.NET平台开发管理代码，并且也必须清楚ADO.NET数据访问模型引入的基本变化。有关.NET开发的更多信息，见http://msdn.microsoft.com/net 。
　　
　　ADO.NET简介
　　
　　ADO.NET是.NET应用程序的数据访问模型。它能用于访问关系型数据库系统，如SQL Server 2000，及很多其它已经配备了OLE DB供应器的数据源。在某种程度上，ADO.NET代表了最新版本的ADO技术。然而，ADO.NET引入了一些重大变化和革新，它们专门用于结构松散的、本质非链接的Web应用程序。关于ADO 与 ADO.NET的比较，见MSDN中的“用于ADO程序员的ADO.NET”一文。
　　
　　ADO.NET引入的一个重要变化是，用DataTable, DataSet, DataAdapter, 和 DataReader对象的组合代替了ADO Recordset对象。DataTable表示来自一个表的行集合，在这方面它与Recordset类似。DataSet表示DataTable对象的集合，及与其它表绑定在一起的关系和限制。实际上，DataSet是具有内置的扩展标记语言（XML）支持的内存中的关联结构。
　　
　　DataSet的一个主要特点是，它对底层的数据源一无所知，而这些数据源可能用于对其进行填充。这是一个分离的用于表示数据集合的独立实体，并且它可通过多层应用程序的不同层由一个组件传递到另一组件。它也可作为XML 数据流被序列化，因而非常适合于不同类型平台间的数据传输。ADO.NET使用DataAdapter对象为发送到和来自DataSet及底层数据源的数据建立通道。DataAdapter对象还支持增强的批更新特性，以前这是Recorder的相关功能。
　　
　　图1显示了完整的DataSet对象模型。
　　　
　　
　　图1 DataSet 对象模型
　　
　　.NET 数据供应器
　　
　　ADO.NET 依靠.NET 数据供应器的服务。 它们提供了对底层数据源的访问，包括四个主要对象（Connection, Command, DataReader,及DataAdapter），目前，ADO.NET只发行了两个供应器：
　　
　　SQL Server .NET 数据供应器。这是用于Microsoft SQL Server 7.0及其以后版本数据库的供应器，它优化了对SQL Server的访问，并利用 SQL Server内置的数据转换协议直接与SQL Server通信。
　　当链接到SQL Server 7.0 或 SQL Server 2000时，总是要使用此供应器。
　　OLE DB .NET 数据供应器。. 这是一个用于管理OLE DB 数据源的供应器。它的效率稍低于SQL Server .NET Data Provider，因为在与数据库通信时，它需通过OLE DB层进行呼叫。注意，此供应器不支持用于开放数据库链接（ODBC），MSDASQL的OLE DB供应器。对于ODBC数据源，应使用ODBC .NET数据供应器。有关与ADO.NET兼容的OLE DB供应器列表，见。
　　目前测试版中的其它.NET数据供应器包括：
　　
　　ODBC .NET 数据供应器。目前Beta 1.0版可供下载。它提供了对ODBC驱动器的内置访问，其方式与OLE DB .NET数据供应器提供的对本地OLE DB供应器的访问方式相同。关于ODBC .NET及Beta版下载的更多信息见.
　　用于从SQL Server 2000中得到XML的管理供应器。用于SQL Server Web升级2版的XML还包括了专用于从SQL Server 2000中得到XML的管理供应器。关于此升级版本的更多信息，见 .
　　名称空间组织
　　
　　与每个.NET数据供应器相关的类型（类，结构，枚举，等等）位于它们各自的名称空间中：
　　
　　System.Data.SqlClient. 包含了 SQL Server .NET 数据供应器类型。
　　System.Data.OleDb. 包含了 OLE DB .NET数据供应器类型。
　　System.Data.Odbc. 包含了ODBC .NET数据供应器类型。
　　System.Data. 包含了独立于供应器的类型，如DataSet及DataTable。
　　在各自关联的名称空间中，每个供应器都提供了Connection, Command, DataReader, 及 DataAdapter对象的实现。SqlClient实现都有前缀"Sql"；而OleDb实现前面都有前缀"OleDb"。例如，Connection对象的 SqlClient实现是SqlConnection。而OleDb实现是OleDbConnection。类似的，DataAdapter对象的两种实现是SqlDataAdapter 和OleDbDataAdapter。
　　
　　通用编程
　　
　　如果你很有可能以不同的数据源为目标，并希望将代码从一种数据源移植到另一数据源，那么可以考虑对System.Data名称空间中的IDbConnection, IDbCommand, IDataReader,和IDbDataAdapter接口进行编程。Connection, Command, DataReader, 及 DataAdapter对象的所有实现都必须支持这些接口。
　　
　　关于实现.NET数据供应器的更多信息，见http://msdn.microsoft.com/library/en-us/cpguide/html/cpconimplementingnetdataprovider.asp.
　　
　　图2显示了数据访问堆栈及ADO.NET如何与其它数据访问技术，包括ADO和OLE DB，联系起来。该图还显示了ADO.NET模型中的两个管理供应器和主要对象。
　　
　　　
　　
　　图2 数据访问堆栈
　　
　　关于ADO到ADO.NET的演化，见MSDN杂志2000年11月期的文章“ADO+简介：用于微软.NET框架的数据访问服务”。
　　
　　存储过程与直接SQL的比较
　　
　　在本文剩余部分的大部分代码片段中，都使用了SqlCommand对象调用存储过程去执行数据库操作。在一些例子中，你见不到SqlCommand对象，因为存储过程名直接传递给了SqlDataAdapter对象，但这仍将导致SqlCommand对象的创建。
　　
　　使用存储过程而非SQL语句的原因是：
　　
　　存储过程通常会使性能增加，因为数据库可以优化过程使用的数据访问计划，并对其进行缓存以备将来重用。
　　在数据库中，存储过程可分别得到保护。客户可以被给予执行某个存储过程的权限，但无权处理底层的表。
　　存储过程将导致维护简单，因为在一个已部署组件内，修改存储过程通常要比修改硬编码的SQL语句简单。
　　存储过程增加了一个从底层的数据库结构中提取出的层。存储过程的客户与存储过程的实现细节及底层结构被隔离开了。
　　存储过程可以降低网络流量，因为SQL语句可以以批处理的方式执行，而不是从客户端发送多个请求。
　　属性与构造函数的比较
　　
　　可以通过构造函数参数或直接设置属性来为ADO.NET对象设置具体的属性值。例如，下面的代码片段在功能上是等同的。
　　
　　// Use constructor arguments to configure command object
　　SqlCommand cmd = new SqlCommand( "SELECT * FROM PRODUCTS", conn );
　　
　　// The above line is functionally equivalent to the following
　　// three lines which set properties explicitly
　　sqlCommand cmd = new SqlCommand();
　　cmd.Connection = conn;
　　cmd.CommandText = "SELECT * FROM PRODUCTS";
　　
　　从性能角度来说，两种方法的差别可以忽略，因为设置或获得.NET对象的属性比对COM对象执行类似操作要有效得多。
　　
　　所作出的选择只是个人爱好和编码风格而已。然而，明确地设置属性的确使代码易于理解（特别是当你不熟悉ADO.NET对象模型时），便于调试。
　　
　　注意 过去，VB开发人员被建议避免使用"Dim x As New…"结构创建对象。在COM环境中，这些代码将导致COM对象创建过程的“短路”，产生一些奇妙的和不怎么奇妙的错误。然而，在.NET环境中，这已不再是一个问题。
　　
　　管理数据库链接
　　
　　数据库链接是一种危险的、昂贵的、有限的资源，特别是在多层Web应用程序中。你必须正确管理你的链接，因为你的方法将极大的影响应用程序的整体升级性。还有，必须仔细考虑在哪儿存放链接字符串。你需要一个可配置的、安全的位置。