Updategram 和 Diffgram

核心提示：企业领域中的开发工作正日益变为更加利用 Internet 的功能和互操作性，重点已经从开发传统的客户端/服务器应用程序（需要严格定义用于交换数据的数据结构和协议）转向了开发使用 xml(标准化越来越近了) 的 Web 应用程序，Updategram 和 Diffgram，与传统的客户端/服务器应用程序一样，Web 应用

企业领域中的开发工作正日益变为更加利用 Internet 的功能和互操作性。重点已经从开发传统的客户端/服务器应用程序（需要严格定义用于交换数据的数据结构和协议）转向了开发使用 xml(标准化越来越近了) 的 Web 应用程序。与传统的客户端/服务器应用程序一样，Web 应用程序也通过 LAN 或 WAN 在不同的逻辑实体之间交换数据。但是，Web 应用程序使用公共 Internet 和 xml(标准化越来越近了)，而不使用专用连接和二进制数据格式。在需要访问和更新存储在关系数据库（如 SQLServer）中的数据方面，大多数 Web 应用程序也和客户端/服务器应用程序相似。Web 应用程序必须从 sql server(WINDOWS平台上强大的数据库平台) 获取 xml(标准化越来越近了) 查询结果，并使用 xml(标准化越来越近了) 格式的数据更新 sql server(WINDOWS平台上强大的数据库平台)。Microsoft 已经通过在 sql server(WINDOWS平台上强大的数据库平台) 2000、xml(标准化越来越近了) for sql server(WINDOWS平台上强大的数据库平台) 2000 (SQLxml(标准化越来越近了)) 和 .NET 框架中实现许多技术满足了这些要求。（有关这些技术的概述，请参阅 2002 年 4 月的“Selecting xml(标准化越来越近了) Technologies for Queries and Updates”，InstantDoc ID 24342。）这些技术为构建各种 Web 应用程序提供了坚实的基础。但是，经过证明，处理数据库更新总是比较困难。

Microsoft 提供了几个用来更新数据库的选项，包括 Openxml(标准化越来越近了)、xml(标准化越来越近了) Bulk Load、updategram 和 Diffgram。我们已经在以前的专栏中研究了 Openxml(标准化越来越近了) 和 xml(标准化越来越近了) Bulk Load；现在，该介绍 updategram 和 Diffgram 了。用来快速构建实际 Web 应用程序方案的每种技术都有很大的缺陷。在这些应用程序方案中，数据从某个 Web 应用程序进行请求、在客户端位置进行远程修改，随后返回到该 Web 应用程序，以便所做的修改可以存储在数据库中。在这些方案中，对于 Web 应用程序有三个隐含要求。第一个是对开放式更新的需求。由于客户端和服务器之间的 Internet 连接是异步的、短暂的并且有可能是不可靠的，因此 Web 应用程序需要进行开放式更新。如果没有开放式更新，则由于在超时之前仍有许多锁，应用程序和数据库性能会迅速降低。第二个要求是，客户端不需要（而且不应当预知）数据库结构。第三个要求是，客户端需要一种方法来传送对数据进行的更改（包括并发信息），以便克服多个客户端对服务器进行的竞争更新。Updategram 和 Diffgram 是相似的技术，它们都在不同程度上支持这三个要求。因此，假设您正在构建 Web 应用程序，那么应当使用哪种技术？

Updategram

updategram 是一种 xml(标准化越来越近了) 文档，它描述对 xml(标准化越来越近了) 查询结果进行的更改。结合使用 updategram 和任何 SQLxml(标准化越来越近了) Web 版本，可以对数据库进行开放式更新。Updategram 还支持更新数据库中与 xml(标准化越来越近了) 中的分层关系相对应的一个或多个表。例如，可以将嵌套在 xml(标准化越来越近了) 定单元素中的定单项插入到数据库的 Order 和 LineItem 表中。尽管 updategram 会尝试满足更新数据的三个要求，但是它们在以下几个方面存在缺陷。

首先，ADO、sql server(WINDOWS平台上强大的数据库平台)、SQLxml(标准化越来越近了) 或对象模型（如 xml(标准化越来越近了) 文档对象模型 (DOM)）不支持 updategram。这种缺陷会从三个方面降低 updategram 的有用性。第一，因为 ADO 和 DOM 不支持生成 updategram，所以您必须实现一个直接生成 updategram 语法的客户端代码。更糟糕的是，这项艰巨的任务不能在项目之间进行缩放；每当您希望生成一个 updategram 时，都必须实现该逻辑。第二，在将数据存储到数据库中之前，Web 应用程序通常需要使用业务逻辑来检验和验证数据。同样，您需要用一个对象模型来表达该业务逻辑（因为该技术使用开放式更新），以便确认在从数据库检索数据之后和尝试更新数据之前之间的这段时间内，数据未发生变化。第三，对象模型在理想情况下可使您能够以一种一致的方式来访问更新的数据和原始值。但是，您也需要实现一个代码，该代码除了执行业务逻辑和并发检查，还要解释 updategram 语法。

Updategram 还有一个缺陷，就是无法调用存储过程来执行数据库更新。因此，通过使用存储过程而实现的业务逻辑、约束和引用完整性都呈现为无用状态。

updategram 用来表达数据集更改的方式可能会造成另一个问题。这些更改是用 xml(标准化越来越近了) 而不是关系数据库表达的。尽管用这种方式表达所做的更改通常大有裨益（这是因为它向客户端隐藏了数据库的详细信息），但是它还可能排除某些数据，而在将所做的更改提交到数据库中之前，您可能需要这些数据来验证所做的更改或执行业务逻辑。

最后，updategram 通常的应用方式也存在缺陷。因为 updategram 最适于进行批处理，所以，如果 sql server(WINDOWS平台上强大的数据库平台) 能够按照它处理 T-SQL UPDATE 语句的方式来处理 updategram 的话，updategram 则会生成最高效的结果。但是，当前的 SQLxml(标准化越来越近了) 实现在中间层处理 updategram，并生成由 sql server(WINDOWS平台上强大的数据库平台) 执行的 SQL 语句，而不是直接处理 updategram。因此，尽管 updategram 从表面看非常适合在 Web 应用程序中更新数据，并且有可能适合一组范围较窄的情形，但是，其缺点限制了对它们的广泛应用。

Diffgram

Diffgram 是随 ADO.NET 支持一起引入 .NET框架中的。Diffgram 与 updategram 相似，但是能够解决 updategram 中一些固有的最严重的问题。最重要的是，Diffgram 通过 ADO.NET DataSet 对象提供对象模型支持。您可以通过持久性保持一个 Diffgram 格式的 DataSet，来直接从该 DataSet 定义中生成 Diffgram，也可以从持久性 Diffgram 中创建 DataSet。因此，当您构建业务逻辑时，不必编写用来生成 Diffgram 或导航 Diffgram 结构的代码。相反，您只需使用 DataSet 对象来编写代码。您还可以结合使用 DataSet 对象和 DataAdapter 对象，将以 Diffgram 表达的更改提交到数据库中。（DataAdapter 是 ADO.NET 中的一个中间对象，它从数据库中读取数据并将所做的更改更新到数据库。）另外，DataAdapter 支持通过存储过程来进行更新，而且会在对数据进行了并发更新之后，引发一个程序事件。尽管对于程序员来说，Diffgram 比 updategram 方便得多，但是使用 Diffgram 也有一些注意事项。

首先，您需要让 .NET 框架充分利用 Diffgram。.NET 框架和公共语言运行库 (CLR) 尚未完全部署，因此 Web 客户端可能还无法访问 DataSet 的丰富功能，或者可能无法在中间层服务器上使用 .NET 框架。第二，Diffgram 不支持对使用标识列的表进行更新。如果数据库架构使用标识列来自动为某些实体生成唯一的 ID，这些实体随后又用于其他表中的外键，Diffgram 则无法处理更新。例如，当定单及其行项目存储在单独的表中，而且使用一个标识列（例如，定单号）做为 LineItems 表中引用其相关定单的外键时，Diffgrams 则无法成功地将行项目添加到数据库中。唯一的解决办法是亲自编写更新代码，以便取消 Diffgram 的值。更大的障碍是，当不同的复杂类型（在 xml(标准化越来越近了) 架构定义 － XSD 中进行定义）使用相同的名称但是位于不同的上下文中时，Diffgram 无法使用 xml(标准化越来越近了)。例如，一般会使用名称“Vendor”来引用 ServiceProvider 类型和 ProductReseller 类型，这两种类型具有不同的结构。如果客户端使用不同的架构（或根本不使用架构）来构建数据集，则在解释 Diffgram 时也可能遇到问题。因为 Diffgram 是对 DataSet 内容进行序列化的过程，所以您收到的 Diffgram 可能与您的数据库或您知道的任何架构都不匹配，因此，更新数据库就变得很难，甚至不可能。

如果 .NET 框架不可用，则 Web 客户端应用程序通常必须生成一个 Diffgram，方法是编写用来构造 Diffgram 格式的代码。但是，在中间层，可以使用替代处理方法。SQLxml(标准化越来越近了) 2.0 和 3.0 可以通过两种方法来处理 Diffgram 并更新数据库：通过 ADO 的 xml(标准化越来越近了) 方言（使用 CommandStream 对象）；通过 SQLxml(标准化越来越近了) 虚拟目录（按照与处理 xml(标准化越来越近了) 模板大体相同的方式来处理 Diffgram）。这两种方法都使用 XSD 映射架构来将 Diffgram 中的数据映射到数据库结构。SQLxml(标准化越来越近了) 使用这些映射信息来处理 Diffgram 并生成 SQL语句，从而按照与处理 updategram 相同的方式来修改数据库。尽管 SQLxml(标准化越来越近了) 将帮助您在安装 .NET 框架之前了解可用于 Diffgram 的支持种类，但是，您仍必须解决我在前面介绍的 updategram 和 Diffgram 问题。

有选择地使用 Diffgram

由于 ADO.NET 能够自动生成 Diffgram，因此 Diffgram 比 updategram 更有用。但是，只有当您的数据库不引用具有外键的标识列，而且您能够控制客户端代码使用的 xml(标准化越来越近了) 架构时，才应当使用 Diffgram。如果能够满足这两个条件，就可以确保成功地解释 Web 应用程序接收的 Diffgram。或许有一天，标准语言将像在 xml(标准化越来越近了) 文档中表示那样来表达对数据进行的更改，而不是基于编程模型处理数据的方式来进行表达。那时，我们将能够快速构建 Web 应用程序，以便在不同的平台、语言、框架和数据库管理系统之间交换数据以及对数据进行的更改。