ADO+ 引导数据种类的演变
Dino Esposito
2000年9月

摘要： 本文讨论了 ADO 的最新版本 ADO+ 所提供的增强的互操作性和可伸缩性。

目录

简介
一种公用数据操纵语言
数据种类
ADO+ 增加了哪些内容
ADO+ 的构成要素
ADO+ 命令
强类型编程
摘要


--------------------------------------------------------------------------------


简介

从一开始，开发软件应用程序就是为了访问某种数据库。分布式应用程序和基于 Web 的应用程序也不例外。然而在分布式方案中，由于可能存在不同的硬件和软件平台或对象模型，事情变得稍微有点复杂。尽管如此，数据就是数据，在几乎任何地方都需要得到交换和处理。

在我们进入可编程 Web 时代 — Internet 的第三个阶段 — 之前，数据访问曾是一个相对简单的问题；主要关心的问题就是选择效能成本最合算的数据库服务器。任何系统的所有模块都必须符合数据库服务器 — 一种对整个系统进行完全控制的全能实体 — 的要求。客户机/服务器应用程序一直是这种模型的典型表现形式。

近来，n 层 Microsoft® Windows® DNA 系统致力于开发能够对几乎任何种类的数据进行迅捷可靠的访问的技术，这些数据种类包括：关系型、非关系型、层次型、半结构化型、分散型、易失型等。这种数据访问的统一方法成为“通用数据访问”策略 — OLE DB 体系结构的鼓舞人心的原则。Microsoft ActiveX® Data Objects (ADO) 的出现完成了一项重大的任务：将成千上万的 Windows 开发人员从过时的客户机/服务器模型带到数据访问组件和 OLE DB 的奇妙世界。

在 Windows DNA 模型中，中间层组件通过 OLE DB 规范体贴地为我们定义的一种公用格式来获取和交换数据。这种格式以行集格式为基础，并且通常被转换为诸如 ADO 记录集之类的一种更高级的结构。

使用 ADO 记录集有得有失。一方面，它们提供了一种丰富并具有吸引力的编程接口。另一方面，它们是严格基于 COM 的，在涉及许多平台（尤其是非 Windows 平台）的分布式异构环境中无法使用。互操作性和可伸缩性是对现代 Web 系统的两个很高的要求；互操作性和可伸缩性更好的数据访问体系结构同样是最新的 ADO 版本 ADO+ 中的主要变化。


--------------------------------------------------------------------------------


一种公用数据操纵语言

通常情况下，目前的分布式系统符合图 1 中所示的体系结构。


图 1. 目前的分布式 Web 系统的典型体系结构

表示层通常基于 HTML 3.2 输出，并能够很好地与任何较新的浏览器一起工作。网页是在 Web 服务器上使用 Active Server Pages (ASP) 构建的，并且只有在一些相当特殊的情况下才试图通过 COM、动态 HTML 和 XML 支持来提供浏览器的实际功能。

关键之处是中间层，其中通常有一层或多层业务对象获取并交换数据来响应用户的输入。这些组件可能需要彼此传递数据，并且在传递数据的过程中，它们需要一种易于使用、功能强大并为所有组件所理解的公用数据格式。ADO 记录集 — 表或视图的 ADO 表示 — 是一个相当不错的解决方案，它有几个优点，并且只有一个大的缺点。

ADO 记录集的灵活性足以使您能够毫不费力地定位记录以及使用过滤器和书签。它们还提供排序、自动分页和持久性等功能，并能在与数据源断开时工作。可以在多层之间相当高效地汇集记录集，这归功于其固有的并且极为紧凑的二进制格式 — Advanced Data Table Gram (ADTG) 格式。

断开的记录集在组件之间的传输涉及到 COM 汇集，并强制接收组件配合这一汇集。换句话说，只有 COM 对象才能使用 ADO 记录集。这在 COM/DCOM 在业务层中占主导地位的同构体系结构中不成问题。显然，当有关的服务器端组件的映射涉及到诸如大型机或 Unix 平台之类的异构节点时，就会带来很大的不便。

所谓的 Internet 的第三个阶段使这一方案离我们更近了。它预示了一个世界，在这个世界中，功能实现通过各种 Web 服务（即可以通过 HTTP 访问的环绕着我们的卫星系统）成为可能。您将需要向这些服务中的某个传递一些记录以进行进一步处理，这个方案并不是什么勉强的事情。没有什么比 Web 服务更加容易的事了 — 不管它的内部体系结构或公共编程接口如何 — 它不接受 ADO 记录集。

A目前现实中的 ADO，特别是记录集，是在 Windows 和基于 COM 的方案中操纵数据的强有力的工具。不幸的是，随着您的系统逐渐向完全的 Internet 互操作性方向演变，它们逐渐丧失了其吸引力。


--------------------------------------------------------------------------------


数据种类

在完美的情况下，应该能够在任何平台或设备上以相同的方式访问数据，并具有相同的灵活性。这样，每个平台或设备都可以根据需要自由地操纵数据。如果您通过 ADO 记录集展示数据，则您也使自己和您的应用程序陷于有限互操作性的实际风险之中。

目前，如果您通过 ADO 对数据进行访问，并希望将其传送到远程组件，您要么使用从数据访问模块获得的相同的 ADO 记录集，要么将其转换为能够通过网络传送的另外的东西，更为重要的是，能够在其最终目的地被理解。如前所述，记录集需要 COM 汇集，举例来说，COM 调用并不是总能穿过公司防火墙。此外，在对 ADO 记录集进行汇集时，总处理时间的很大部分是用于完成必要的类型转换。事实上，您必须确保记录中的所有的值映射到 COM 能够识别并知道如何进行处理的有效数据类型。

在有关的组件在物理上是分开的并在不同的机器上运行时，COM 汇集因素变得更为重要。因此，在向完全由 Internet 连接起来的世界前进的过程中，目前的 Windows 数据种类连同 ADO 记录集必须有所发展才能继续存在下去。

需要示例吗？在 MIND 的 2000 年 1 月号（英文）以及 MSDN Magazine 的 2000 年 3 月号（英文）中的 Cutting Edge 专栏中，我对将远程脚本 (RS) 用作一种从远程 ASP 页面获取数据而不定位到该页面的跨浏览器的技术进行了说明。当您以这种方式调用某一页面上的远程函数时，RS 基础结构提供将函数返回的内容发送回客户机。在大多数情况下，您需要返回一个记录集。然而，由于安全性原因，RS 甚至不会尝试连同任何其它 COM 对象对某一 ADO 记录集进行处理。因而，如果使用 RS，您必须避免使用 ADO 记录集，而应当使用数组或字符串传递所请求的信息。在 2000 年 3 月的专栏中，我通过从记录集构建一个 JavaScript 对象对这一内在的限制进行了说明。ASP 页面通过 ADO 获取数据，并在返回调用程序前将其转换为一个 JavaScript 对象：

rst = new ActiveXObject("ADODB.Recordset");
rst.open("select * from employees", "DSN=Northwind");
oRS = new Recordset(rst);
rst.close();
return oRS;

客户机页面通过 RS 运行时接收这一对象，并可以根据需要对其进行处理，这比通过字符串或数组要容易得多。详细信息和源代码，请参见我的 2000 年 3 月 Cutting Edge 专栏文章（英文）。

我们从这里可以学到些什么吗？对于超出单一客户机或服务器端平台的数据互操作性，我们需要对 ADO 模型进行一个较小的改变。

我们需要改变是由于跨平台模块的交互作用需要一个通用数据模型。此外，我们不希望这个改变太大，原因是 ADO 内还存在若干很好的功能，放弃它们是一件可惜的事情。

JavaScript Recordset 对象，就其内