智能客户端 Offline Application Block 简介

简介

发布日期： 8/6/2004 | 更新日期： 8/6/2004

简介

Microsoft Corporation

摘要：第 1 章介绍 Offline Application Block 并探讨对于理解应用程序块非常重要的概念。

本页内容

	应该阅读本指南的人员
	前提条件
	章节概述
	智能客户端和脱机功能
	启用脱机功能
	何时适用脱机操作？
	Offline Application Block
	客户方案
	小结
	更多信息

智能客户端是位于用户本地 PC 上的应用程序，同时具有网络感知功能。在这里，我们认为它们已连接到网络（通常指 Internet），并且可以自动下载或上载对软件、数据和工作项目的更新。

本指南介绍了可以合并到智能客户端应用程序中的 Offline Application Block 的设计和功能。通过将 Offline Application Block 合并到代码中，您可以扩展智能客户端应用程序的功能，使之能够下载数据，并在断开网络连接的情况下仍然可以正常工作。例如，在连接时，应用程序将能够存储由 Web 服务公开的数据，然后当用户不再连接到该服务时，使用户能够处理该数据。

下面是本指南的前提条件及其内容大纲的概述。

应该阅读本指南的人员

本指南是为开发针对 PC 的智能客户端应用程序的软件架构师和开发人员而编写的。（个人数据助理 [PDA] 和其他替代设备不在本指南的讨论范围之内。）

返回页首

前提条件

要从本指南中充分受益，您应该了解以下技术：

•	Microsoft Visual C#(R) 开发工具
•	Microsoft Visual Basic(R) 开发工具
•	.NET 框架
•	可扩展标记语言 (XML)
•	Microsoft SQL Server™ 桌面引擎 (MSDE) 开发工具
•	消息队列 (MSMQ)
•	多线程

返回页首

章节概述

第 1 章的其余部分提供 Offline Application Block 体系结构的高级说明，并包含一个将在第 2 章中进一步开发的客户方案。下面是本指南其余章节的摘要：

•	第 2 章分析了 Offline Application Block 的功能、体系结构、设计以及与支持它的其他组件（例如 Caching Application Block）的关系。
•	第 3 章介绍了应用程序块代码随附的 QuickStart。在您了解 Offline Application Block 的功能之后，就可以将该应用程序块用于您的开发过程。每个 QuickStart 向您介绍一项功能、一个代码概念或一个复杂任务，同时还包含示例代码。所提供的 QuickStart 包括： • 连接管理 QuickStart • 下载 QuickStart • 上载 QuickStart • 保险索赔 QuickStart
•	第 4 章说明如何配置、部署并保护您的应用程序。
•	“参考资料”部分介绍了在 Offline Application Block 中使用的类。
•	附录 A 介绍了用于测试 Offline Application Block 的测试案例。

返回页首

智能客户端和脱机功能

在出现智能客户端之前，应用程序分为胖客户端和瘦客户端。胖客户端将所有应用程序都存储在客户端计算机上，并具有能够显示复杂图形和动画的用户界面。另一方面，瘦客户端将所有应用程序都存储在服务器上。基本上，它只负责检索和显示数据。瘦客户端的主要问题是：数据需要往返很多次才能传输到服务器，从而降低了性能。胖客户端的主要问题是：分配比较复杂并且会导致端口问题。智能客户端是一种解决方案，它结合了这两种方法的最佳功能。

智能客户端提供了与胖客户端同样充足的接口，同时还可以有效地管理内容更改。此外，智能客户端可以在提供这些功能的同时最小化它所使用的资源（例如，磁盘空间和内存）。

智能客户端还可以利用某些 .NET 功能（例如，可以自动部署和更新应用程序），并且可以设计为在脱机时正常运行。有关这些功能和其他功能的详细信息，请参阅 Overview of Smart Client Applications in the Microsoft Office System。

返回页首

启用脱机功能

用户经常要求智能客户端应用程序在断开网络连接后可以继续运行。在智能客户端应用程序中，有两个方法可以启用脱机功能：以数据为中心的方法和面向服务的方法。使用以数据为中心的方法，客户端可以使用本地数据库和复制机制，以便在脱机模式下管理对数据的更改。使用面向服务的方法，客户端可以通过服务请求与许多服务进行交互。如果应用程序处于脱机模式，它可以推迟服务请求，直到重新连接至 Web 服务。

每种方法都有其优点和缺点，且适用于不同类型的应用程序。我们的重点在于面向服务的方法，但为了保持完整性，我们将介绍这两种方法。图 1.1 展示了面向服务的方法和以数据为中心的方法。

图 1.1.面向服务的方法和以数据为中心的方法

以数据为中心的方法

与服务器上的数据相结合的应用程序使用以数据为中心的方法。本地数据库管理对本地保存的数据所作的更改，然后使用合并复制将这些更改传回服务器。

首先，客户端创建对所需数据的订阅，这样客户端就可以在脱机之前将该数据复制到本地数据存储区中。一旦客户端脱机，它将通过对本地数据存储区的调用，对本地数据进行更改。然后，当客户端重新联机时，数据存储区的合并复制机制将对客户端数据所作的更改传回服务器。对服务器数据所作的更改也可能会传到客户端。在合并阶段遇到的任何冲突，将根据服务器或客户端上指定的冲突解决规则，或根据数据存储区管理员定义的自定义规则来进行处理。

以数据为中心的方法包括以下特点：

•	该方法以数据库的列级别和行级别提供可靠的数据冲突检测。此外，它还提供数据验证和约束。
•	客户端与数据存储区相结合，这意味着对数据存储区架构所作的更改会直接影响客户端。客户端可以为其订阅的数据存储区提供脱机支持。
•	合并复制是一个两层体系结构，因此在可管理性和可维护性方面受到约束。
•	该方法要求在客户端上安装本地数据存储区（例如，SQL Server for Windows CE (SQLCE) 或 MSDE），以便与服务器进行复制。这可能不适用于运行在小型设备或要求简易部署机制的设备上的应用程序。
•	所有更改跟踪代码都包含在相关数据库管理系统 (RDBMS) 的内部。您不需要编写其他更改跟踪代码或冲突检测和解决代码。

有关以数据为中心的方法的详细信息，请参阅 Merge Replication。

面向服务的方法

智能客户端是面向服务解决方案的组成部分，它可以通过服务请求与网络上的服务进行交互。这些服务可能作为 Web 服务来实现，或者通过某种其他机制来实现，但是该方法的基本特征是：客户端并没有与它使用的服务紧密结合在一起，客户端和服务是彼此独立的。

在此方法中，客户端可以自由地与所需的任何服务进行交互。此外，客户端将重点放在服务请求本身上，而不是放在对本地保存的数据进行直接更改上。服务请求可能会导致客户端或服务器上的状态更改，但这些更改只是服务请求的副作用。

面向服务的方法包括以下特点：

•	脱机逻辑封装在客户端上。
•	客户端数据架构可以不同于服务器上的架构。
•	自定义的业务逻辑可决定冲突检测和解决。
•	实现面向服务的方法需要更多的设计和编码。

要在脱机工作时支持智能客户端，需要使用一个允许存储服务请求详细信息的基础结构，这样当客户端重新连接到网络时，就可以执行这些服务请求。这样的基础结构由下列四个主要元素组成。

•	服务代理 – 服务代理提供服务的主要访问点。它管理客户端与服务的所有交互，并封装所有必要的逻辑以允许客户端创建服务请求。
•	服务请求 – 服务请求的所有详细信息都封装在一个服务请求对象中。然后，服务请求保留在服务请求队列中，直到执行程序组件可以对它们进行处理。服务请求对象负责发出实际的服务请求。
•	服务请求队列 – 该队列为服务请求对象提供持久的存储区。
•	执行程序 – 当客户端重新连接到网络时，执行程序负责从队列中提取服务请求并执行它们。在服务请求完成后，执行程序会通知服务代理，以便它可以通知客户端。

图 1.2 展示了这四个元素，并显示了它们之间的关系。可以将此图看作使用面向服务方法的组件中所必须包括的功能的表示。还可以将它看作此类组件所具有的类的表示。

图 1.2.面向服务的方法的四个组件

除了上述四个元素外，还需要考虑许多其他问题，然后才能将脱机支持构建到智能客户端应用程序中。例如，必须具有某种形式的通知机制，以便执行程序可以开始或挂起队列中的服务请求。为此，Offline Application Block 提供了一个“连接状态管理”组件。

返回页首

何时适用脱机操作？

在决定如何设计应用程序以便脱机使用时，您需要考虑希望用户能够在脱机状态下执行的任务。某些任务在应用程序断开连接时是没有意义的，而某些任务在脱机状态下只能部分完成。

注 在与应用程序进行交互时，任务是用户期望能够完成的分散、独立的工作单位。

要求单个服务请求的任务非常适合脱机方案。此类任务遵循“先编写后转发”模型，在此模型中，用户指定服务请求所要求的所有数据，然后在客户端重新连接时将其转发给实际服务。此类任务的示例有：撰写电子邮件、撰写会议邀请函和输入订单信息等。所有这些任务都是独立项目，用户可以脱机完成它们，并且它们只产生单个服务请求。

相比而言，要求完成多个服务请求的任务在脱机状态下很难管理，这是因为在应用程序重新连接到网络之前，中间服务请求的结果是不可用的。对用户而言，在重新连接之前，任务将显示为挂起，这样会导致不好的用户体验。

在考虑任务如何与后端服务进行交互时，您还需要考虑哪些数据需要缓存到客户端上以支持这些任务。在客户端应用程序脱机之前，必须对这些数据进行检索。这意味着任务参考数据、其有效性和其他约束都需要经过仔细考虑。

所有用户应用程序的一个基本考虑事项是使它们尽可能的直观。用户应该能够轻松地区分哪些任务是挂起同步、何时发生同步、哪些任务已经成功完成以及哪些任务尚未成功完成。脱机时不可用的任务应在它们相应的菜单项或工具栏按钮上显示为禁用。

返回页首

Offline Application Block

必须将某些特定功能构建到应用程序中，以支持脱机工作的功能。它们包括：

•	检测网络连接是否存在，这样可以使应用程序能够根据其联机或脱机状态来执行
•	缓存必要的数据，这样即使在网络连接不可用时，应用程序也可以继续运行
•	当网络连接可用时，将客户端应用程序的状态和/或数据与服务器同步化

Offline Application Block 提供可用于将这些脱机模式功能构建到应用程序中的可重复使用的代码和建议。它还可以利用其他块组件。例如，它可以使用 Caching Application Block 来利用缓存，并将 Caching Application Block 作为其参考数据缓存的基础。

有关缓存应用程序块的详细信息，请参阅 Caching Application Block for .NET。

要点 智能客户端应用程序必须设计为支持脱机功能。您不能简单地将 Offline Application Block 插入现有的应用程序，然后期望它正常工作。例如，如果您下载了该应用程序块并将其合并到一个现有的应用程序中，您将无法强制该应用程序脱机 — 您必须将该功能设计到智能客户端中。该应用程序块确实可以提供有助于您理解该过程的示例，但该应用程序块并不是现成的产品，示例只是作为建议而提供的。

因为 Offline Application Block 使用面向服务的方法，所以它所包含的功能（或类）与图 1.2 中所示的功能相对应。下面的图 1.3 展示了 Offline Application Block 的相应子系统，它们是松散耦合的组件。

表 1.1 说明了图 1.3 中显示的每个子系统。

表 1.1 块元素的定义
子系统	说明
连接状态管理	“连接状态管理”检测应用程序是处于联机状态还是脱机状态。有两种方法可以判断连接状态：手动判断或通过自动过程判断。如果选择自动判断，则连接状态表示为包括网络层和应用程序连接的多层连接性（请注意，应用程序连接检测并不是在该应用程序块中实现的）。应用程序的行为会根据连接状态而变化。
服务代理管理	“服务代理管理”与 Offline Application Block 的这些元素（“消息数据管理”、“参考数据管理”）以及服务器进行交互。它会进行协调，以便将任务完成通知返回到应用程序。
参考数据管理	“参考数据管理”与“服务代理管理”和“消息数据管理”配合工作，以下载存储在本地计算机上的参考数据。在大多数情况下，参考数据是用于完成工作流的只读数据。“参考数据管理”可使参考数据与服务器上的数据保持一致。它将消息存储在“队列”中以下载参考数据。然后，“执行程序”将使用消息服务请求与服务连接，以下载参考数据。
消息数据管理	消息数据是在工作流过程中创建的数据。当应用程序处于脱机状态时，该数据将存储在一个本地队列中。当应用程序联机后，“执行程序”会从“队列”中删除消息，发出与服务器同步数据的“服务请求”，然后数据就会与服务器进行同步。

安全性

Offline Application Block 并不提供安全架构。但是，它支持缓存和队列中存储的所有数据的加密和签名。加密和签名的使用不是强制性的，但强烈建议您使用。通过使用这些安全措施，应用程序可以在将数据临时存储在硬盘上时对数据进行保护。有关安全性和加密的详细信息，请参阅第 4 章。

返回页首

客户方案

本部分提供了一个要求脱机功能的业务应用程序的示例。我们将在整个指南中使用这个方案来阐述 Offline Application Block 中的每个子系统的功能。

David Campbell 是 Humongous Insurance 的保险理赔协调员。他负责华盛顿西部地区的业务，并经常在他客户的居住地或工作地点之间奔走以完成理赔。Humongous Insurance 分析了从理赔的初始阶段到最终阶段的过程流，认为理赔协调员在离开办公室期间输入详细信息是非常重要的。开发小组的挑战和解决方案就是创建一个脱机环境，使保险协调员能够以电子方式完成理赔。

Humongous Insurance 要求应用程序能够检测其连接状态（是联机状态还是脱机状态）。根据脱机组件的设计，保险协调员的用户体验可能会（或者不会）根据连接状态而改变。可以将脱机组件设计为使联机/脱机的变化显而易见。

在脱机工作的准备过程中，应用程序必须下载工作项目以及与每个工作项目相关的关联参考信息。此外，应用程序将在脱机时执行业务逻辑。

当理赔协调员在脱机状态下输入数据时，该数据会保存在消息中。在建立与企业网络的连接之前，消息将被本地存储。在连接到企业网络后，脱机环境会自动将消息与 Web 服务同步。

这些功能为 David 提供了无缝的应用程序环境（无论是联机状态还是脱机状态）。

返回页首

小结

本章阐述了智能客户端的前提条件，并提供了 Offline Application Block 重要概念的概述。这些概念包括：

•	智能客户端使用面向服务的方法启用脱机功能。
•	脱机功能最适用于使用单个服务请求的任务。
•	脱机功能允许用户从网络下载数据，然后在与网络断开连接的情况下处理数据。
•	Offline Application Block 由下列子系统组成： • 与其他子系统和服务器进行交互的“服务代理管理” • 检测应用程序处于联机状态还是脱机状态的“连接状态管理” • 下载参考数据（该数据将存储在本地机器上）的“参考数据管理” • 在脱机状态下处理数据请求的“消息数据管理”

返回页首

更多信息

下列链接提供了有关 Patterns and Practices、智能客户端和其他应用程序块的详细信息，您可以使用这些链接来查找更多信息。

Patterns and Practices

Patterns and Practices Library

Overview of Smart Client Applications in the Microsoft Office System

Application Architecture for .NET:Designing Applications and Services

转到原英文页面

返回页首

 

<script language=javascript> var framesValid = false; if (window.name == "MNPMainFrame") { var menuFrame = parent.frames["MNPMenuFrame"]; if (menuFrame) { framesValid = true; } } if (!framesValid) document.forms["MNPFramesForm"].submit(); else document.write('

'); top.document.title = self.document.title; </script>