本页内容
 |
简介 |
|
表示层的重要性 |
|
什么是瘦客户端？ |
|
什么是智能客户端？ |
|
选择正确的交互层体系结构 |
|
客户端平台 |
|
部署和更新 |
|
用户体验 |
|
性能 |
|
客户端集成 |
|
脱机功能 |
|
小结 |
|
资源 |
简介
表示层是应用程序中至关重要的一部分 — 构建不适当的表示层可能会导致复杂性太高、缺少灵活性，并使得用户体验效率低下、不尽人意。众所周知，在部署和可管理性方面，瘦客户端应用程序比传统的胖客户端应用程序更具优势，这使得它们在近些年颇受欢迎。但是，随着智能客户端的到来，表示层体系结构的选择不再那么直捷了当了。胖客户端已经演变为智能客户端，综合了瘦客户端在中央管理方面的优势，以及胖客户端的灵活性、更佳的响应效果和高性能。本文讨论了瘦客户端和智能客户端方法，并提供了有关如何在它们之间进行选择的指南。
表示层的重要性
大多数应用程序的表示层对于该应用程序的成败常常都是至关重要的。表示层实际上代表了用户和应用程序其余部分之间的接口。打个比方说，它就是轮胎和路面接触的地方。如果用户与应用程序的交互方式不能使他们以高效和有效的方式执行自己的工作，那么应用程序在总体上的成功将大打折扣。
就我个人看，我认为表示层这个术语实在不足以表示这个层的功能和重要性。它很少只是向用户显示信息 — 更常见的是向用户提供对应用程序的交互性访问。可能对于这个层来说，更为适当的名称是用户交互层。不过，为简单起见，在本文中，我将继续使用这个层的广为人们接受的名称。
无论如何，在设计这个层时，您都希望向用户提供适当的用户体验，使用户能够以有效和高效的方式与应用程序进行交互。当然，在构建这个层的体系结构然后实现它时，您还需要充分地考虑业务的开发、维护和运行需要。为应用程序的表示层选择正确的体系结构，对于实现这些目标来说，极其重要。
瘦客户端方法和智能客户端方法是两种常被采用的表示层体系结构和设计方法。当然，有许多因素会影响有关哪种方法最适用于特定应用程序的决策 — 如客户端平台要求、应用程序部署和更新、用户体验、性能、客户端集成、脱机功能等 — 而各种方法都有与生俱来的优点和缺点，自然而然地支持某种特定样式的应用程序。但是，您会发现，它们之间的区别可能被混淆，而这很容易导致应用错误的基本方法，进一步导致以后的问题。
例如，有人可能会使用基于浏览器的表示层来提供胖用户界面，同样，另一些人则可能会使用智能客户端提供完全动态的用户界面。这两者实现起来都不容易，而且都很可能会导致不必要的复杂性、缺乏灵活性以及高昂的开发和维护成本。
许多单位不加思索地选择瘦客户端体系结构，而没有充分考虑其他方案。虽然并不能适用于所有情况，但智能客户端体系结构可以提供比瘦客户端方法显著优越的优点，而不会带来传统上与胖客户端相关联的缺点。单位应当审慎地考虑各种方法，以便能够从开始就选择正确的方法，尽可能降低应用程序整个生存周期的 TCO。
在下面的部分中，我将对瘦客户端和智能客户端方法以及它们幕后的一些技术进行探讨。对于每种方法，我将介绍其基本体系结构，并讨论该方法内的一些设计选项。之后，我将以您在为自己的应用程序确定最佳方法时需要考虑的一些常见因素和要求为前提，讨论各个方法的相对优缺点。
什么是瘦客户端？
许多瘦客户端技术都是有关服务器端的，而目前有许多 Web 服务器平台和框架（ASP、ASP.NET、JSP 及其他）可供选择。每种平台都具有一些特定的功能，试图简化编写瘦客户端应用程序的过程，但它们都通过一系列 HTML 页面来向客户端上的浏览器提供用户界面。瘦客户端应用程序可以很简明地定义为：使用浏览器来提供应用程序（以 HTML 定义的）用户界面的执行环境的客户端应用程序。
除了呈现用户界面和允许用户与之交互外，浏览器还提供一般的安全性、状态管理和数据处理功能，外加所有客户端逻辑的执行环境。对于后者，浏览器通常会提供一个脚本引擎和承载其他可执行组件（如 Java Applets、ActiveX 和 .NET 控件等）的能力（虽然大多数定义并不认为这些可执行组件属于瘦客户端技术 — 参见下面的混合型应用程序）。
体系结构被构建为使用瘦客户端表示层的应用程序可以分解为一些页面，而每个页面都在被请求时“部署”到客户端。每个页面都包含用户界面说明，并通常会包含少量客户端脚本逻辑和少量状态/数据（视图状态、Cookies、XML 数据岛等）。图 1 所示为一种瘦客户端表示层体系结构的图形表示。
浏览器与客户端环境（硬件和在客户端上运行的其他软件应用程序）交互的能力是有限的。它的确提供了一种使得能够在客户端上存储少量数据（通过 Cookies）的机制，有时还提供缓存页面的能力，但除了作为分别提供简单的会话管理或跟踪，以及基本的只读脱机功能的一种方法外，这些功能作用有限。
浏览器还提供安全性基础结构，以便使不同的应用程序（页面）能够分配到更多或更少的权限，这样，它们就可以围绕状态（如 Cookies）执行不同的任务，就可以承载组件和执行脚本。Internet Explorer 通过不同的区域、受信任站点、分级等实现了这些功能。
为了提供更丰富、响应效果更佳的用户界面，一些 Web 应用程序采用了 DHTML 和类似的技术来提供更为丰富的用户界面。虽然这些技术是非标准的，即并不是所有的浏览器都以相同的方式支持它们，但它们的确提供了在 Web 页面中包括更高级的用户界面元素（如下拉菜单、拖放等）的能力。
图 1：瘦客户端体系结构的图示
其他的 Web 应用程序采用了在页面内承载复杂组件（包括 Java Applets、ActiveX 和 .NET 组件）的方法。这些组件要么可以提供响应效果更佳的用户界面，要么提供出于性能或安全原因而不能在脚本中实现的客户端逻辑。正是在这里，瘦客户端开始与智能客户端发生重叠，导致出现所谓的混合型应用程序。
您当然可以使用这样的混合型应用程序来利用或规避各种方法的优缺点，但在本文档中，我将把术语“瘦客户端”定义为指代不依赖于这些组件，而仅使用浏览器环境所提供基本功能的通用 Web 应用程序。由于混合型应用程序需要依赖于智能客户端功能来避免管理和运行问题，我将在稍后介绍智能客户端应用程序的部分中对其进行介绍。
什么是智能客户端？
智能客户端应用程序可能不像瘦客户端应用程序那么容易定义，这是因为它们可以采取许多种不同的形式，而不限于瘦客户端应用程序那样一成不变的方式。智能客户端和瘦客户端之间的主要区别在于智能客户端不依赖于浏览器来为其操作提供执行、安全性和用户界面环境。此外，智能客户端（而不是 HTML 和 Jscript）通常采用在客户端计算机上运行的已编译代码部件（组件、程序集等）来提供应用程序的用户界面和客户端逻辑。
智能客户端与胖客户端有何关系？胖客户端应用程序已经发展为智能客户端应用程序。相较于瘦客户端应用程序，胖客户端提供了许多优点，包括改进了的性能、更佳的响应效果和灵活性以及脱机工作的能力，但是在以可靠的方式部署和更新方面，胖客户端存在一系列运行问题。瘦客户端解决方案当然地在部署和更新方面更具优势，这也是它们受欢迎的一个主要原因。
但是，智能客户端应用程序通过借鉴瘦客户端应用程序的可管理性优势，并结合以胖客户端应用程序的优点，代表了一种面面俱到的方法。智能客户端是革除了劣势的胖客户端，通过采用新技术和技巧避免了传统胖客户端应用程序的缺陷。
例如，构建在 .NET 平台上的智能客户端应用程序可以利用一系列 .NET Framework 用以解决传统上与胖客户端应用程序相关联问题的重要技术。虽然始终都可以生成最小化或者避免了部署和安全缺陷的胖客户端应用程序，但 .NET Framework 提供的功能大大简化了这一工作。
.NET 提供了从 Web 服务器部署应用程序或应用程序一部分的能力。这种技术称为无接触部署 (No-Touch Deployment)，使您能够通过 URL 部署应用程序。这使得您能够将应用程序发布到一个中心位置（即发布到一台 Web 服务器），这样就可以根据需要自动部署该应用程序。所有客户端都可以自动保持最新状态，这是因为应用程序会在每次应用程序运行时自动检查更新，且每个客户端应用程序在必要时都可以下载新的代码。
图 2：智能客户端体系结构的图示
.NET 还提供了代码访问安全性 (CAS) 基础结构。CAS 根据它所提供的证据分配 .NET 代码特定的权限。CAS 提供与瘦客户端应用程序中的浏览器大致相同的功能，提供应用程序运行的沙箱环境。无接触部署可以与 (CAS) 集成。默认情况下，使用无接触部署部署的应用程序将被根据部署它们时所处的 URL 区域授予一组有限的权限。网络管理员可以通过安全策略来修改权限，这样，就可以根据需要授予或者拒绝给予应用程序特定的权限。
使用 .NET Framework 创建智能客户端应用程序，可以得到更为稳定的应用程序。以前，安装胖客户端应用程序可能会导致其他应用程序被破坏，这是因为它会替换其他应用程序共享的重要组件和 DLL。.NET 允许分离应用程序，将所有的应用程序部件存放在一个本地目录中，这样，所有的程序集都是分离的。而且，这样的应用程序在部署时并不需要任何注册过程，从而进一步降低了破坏其他应用程序的风险。此外，.NET Framework 允许并列部署一个程序集的多个版本。这确保了在执行一个应用程序时，该应用程序是使用生成和测试它时原本版本的程序集运行的。
体系结构被构建为使用智能客户端作为其表示层的应用程序通常会提供一个中央部署服务器（通过该服务器，可以将智能客户端的部件部署到客户端）和一些提供对后端业务功能（即智能客户端使用的业务逻辑和数据）进行访问的 Web 服务。由于智能客户端在客户端上运行代码，因此它可以更为明晰地将用户界面与客户端数据和逻辑分开。此外，视它被授予的权限而定，它可以更为自由地与其他客户端资源（如本地硬件和客户端上运行的其他软件）进行交互。图 2 所示为这种体系结构的图示。
智能客户端是什么样子的？智能客户端应用程序可以采取多种形式，这种应用程序的架构师需要应对多种设计选择。要作出的第一个决策是选择最适当的应用程序样式 — 即向用户显示智能客户端的方式。通常，设计智能客户端应用程序的方法有三种：
| • | Windows 应用程序。传统的 Windows 样式的应用程序，通常使用 Windows 窗体或者在 .NET Compact Framework 上生成的的移动应用程序生成。 |
| • | Office 应用程序。经过扩展包括了智能客户端功能的 Microsoft Office 程序，将用户与商业应用程序和业务处理连接了起来。混合型应用程序。结合使用瘦客户端和智能客户端技术的应用程序。例如，在浏览器页面内承载 Windows 窗体控件，或者在 Windows 窗体应用程序中承载浏览器的应用程序。 |
如果您想充分实现智能客户端方法的优点，那么选择正确的应用程序样式就非常关键。部署、安全性、开发和脱机功能都影响智能客户端应用程序样式的选择，但是可能要考虑的最重要的因素还是总体的用户体验。每个选项都代表不同类型的用户体验，如果选择正确，用户将可以得到他们所需要的灵活性和性能的完美组合。
Windows 应用程序
用户会将智能客户端应用程序与传统的 Windows 样式的应用程序相联系，这是因为它们提供了胖客户端功能，包括工具栏、菜单栏、上下文菜单、拖放支持、上下文相关的帮助、撤销/重复等。开发人员可以在 .NET Framework 或者 .NET Compact Framework 上生成这些类别的智能客户端应用程序，使用 Windows 窗体来提供这些胖用户界面功能。
这些开发人员还可以通过利用 Microsoft Patterns and Practices 工作组提供的应用程序块 (Application Blocks) 来利用预建的智能客户端功能。这些块可以向应用程序提供常见的智能客户端功能，如本地数据缓存、无缝部署和脱机工作的能力。
Windows 窗体应用程序可以提供对用户体验的最大程度的控制，开发人员能够精心设计用户界面和用户交互模型，充分满足自己的需要。对于需要特定的用户体验，而这种体验又不是任何 Office 应用程序本身能够提供的应用程序来说，采用这种方法最合适。
Office 2003 智能客户端应用程序
Microsoft Office 程序提供了一种非常优秀的生成智能客户端解决方案的平台。扩展 Office 应用程序，使之形成分布式解决方案的一部分，将它们连接到远程数据源和业务服务，不仅对用户有利，还可以提高编写应用程序和需要部署和管理它们的开发人员的效率。
许多用户很熟悉 Office，在日常工作中都会用到它。通过将 Office 应用程序连接到远程数据源和业务服务来扩展这些应用程序，意味着解决方案可以从用户对这些程序的熟悉中得利，从而避免或者大幅降低了重新培训用户的需要。对用户也有好处，这是因为他们可以继续使用自己熟悉的应用程序。
许多单位广泛使用了 Microsoft Office。大多数商业 PC — 您的、您客户的、服务提供商的和供应商的 — 都安装了 Office 应用程序。使用 Office 作为商业系统的客户端，可以降低安装和维护递增的客户端应用程序以访问后端数据源和服务的需要。常见的是，来自商业应用程序的数据被复制到 Office 应用程序（如 Word 或 Excel）中以进行进一步的操作、编辑、分析和呈现。复制和粘贴不光耗时，而且还带来了发生错误的风险。更重要的是，指向数据的链接丢失，因此用户需要不断刷新，重复复制和粘贴过程，这可能会带来并发问题。
Office 应用程序还可以提供显示和操作数据所需的众多功能，使用户能够利用 Office 的全套工具与解决方案交互。这可以节省大量时间和工作量，使您能够更快地开发和发布解决方案。例如，Excel 提供了用以排序、操作和显示数据的强大功能。在您的智能客户端解决方案中重用这些功能可以大幅节约成本。
当然，用户在一段时间内可以将其他功能集成到他们的 Office 应用程序中。某些情况下，这导致了一些非正式但是对于业务很关键的解决方案，这些解决方案很难管理，这是因为它们并不是由 IT 部门开发和维护的。使用智能客户端技术生成这些解决方案使得部署和更新它们将更为简便，这是一种能够保留解决方案的价值，并同时解决其中的一些可管理性问题的方法。Office 2003 支持将智能客户端功能集成到 Office 应用程序中，并将它们连接到提供数据和业务处理访问的远程服务。以下是一些 Office 2003 支持的用于创建智能客户端解决方案的更为重要的技术：
| • | XML 支持。Office 2003 提供了一些功能，使开发人员能够通过 XML 更为简便地将 Office 应用程序连接到远程数据源和业务处理。 |
| • | Word、Excel 和 InfoPath 可以使用 XML 以人或计算机可读的 XML 形式存储文档的内容和结构。Microsoft 已经为这些文件格式发布了 W3Ccompliant XSD 架构，任何人都可以在自己的解决方案中免费使用这些架构。这些架构使得能够在服务器上轻松地构造 Word 和 Excel 文档以及 InfoPath 表单，并通过 XML Web 服务提供给客户端，用户则可以方便地显示和编辑这些文档。这种技术还可用于提供文档撰写、索引或者搜索功能。当然，由于这些文档是 XML，因而可以与任何其他系统或过程交换它们，这提供了一种跨异类系统的数据互换方法。这种技术非常适合以文档为中心的解决方案。 |
| • | Word、Excel 和 InfoPath 也可以使用符合自定义或用户定义架构的 XML 消息或文档。用户可以将他们的 Office 应用程序在以数据为中心的解决方案中用作表示层服务，在这种解决方案中，业务处理或服务已经定义了消息架构。这种类型的智能客户端应用程序将消息中的元素和属性映射到文档的特定区域，以使 Office 应用程序正确地显示它们，并在确保用户输入的数据符合基础架构的同时允许用户编辑值。使用 XPath 查询语句，可以以编程方式查询、设置或引用特定的值。“扩展 Office 应用程序，使之形成分布式解决方案的一部分，将它们连接到远程数据源和业务服务，不仅对用户有利，还可以提高编写应用程序和需要部署和管理它们的开发人员的效率。”JOURNAL4 | Choosing the Right Presentation Layer Architecture 9 |
| • | 智能文档。智能文档解决方案通过根据用户在文档内的当前位置向用户提供附加数据和指南，帮助用户与文档进行交互。在用户与文档交互时，它可以使用任务窗格向用户显示相关的信息或指南，或者，它会根据当前的任务自动填充缺少的数据。将这种体验连接到远程服务以获取活动数据或启用与业务处理的交互，将能够生成强大的集成式应用程序。 |
| • | 信息桥框架 (IBF)。IBF 是一种声明式解决方案，构建在智能文档技术之上，使文档能够通过元数据连接到服务。Office 应用程序内的智能标记与通用 IBF 基础结构和与可用的 Web 服务相关联的元数据进行交互，根据文档的内容和用户的当前活动，从文档内提供对相关数据和业务处理的访问。例如，如果用户收到了一个文档，其中提到了某个特定的提供商，IBF 基础结构就可以访问有关该公司的数据，并在任务窗格中显示。它还可以提供对可用选项的访问，使文档能够连接到其他业务处理。 |
| • | Visual Studio Tools for Office (VSTO)。VSTO 提供对 Word 和 Excel 的托管代码扩展的对象模型的访问。开发人员可以使用 VSTO 生成复杂和综合性的 Office 智能客户端解决方案，不仅提供对 Word 和 Excel 的全部功能的访问，还可以访问 .NET Framework 的所有功能，如 Windows 窗体，从而可以轻松地集成丰富并具有优秀响应效果的用户界面。VSTO 还能够提供绝佳的开发体验，使开发人员能够方便地创建和调试解决方案。VSTO 基本上提供了文档后的代码，以便形成能够利用“宿主”应用程序所提供功能的解决方案。 |
混合型应用程序
混合型智能客户端应用程序结合了智能客户端和瘦客户端方法。它们提供了一种用智能客户端功能扩展现有瘦客户端应用程序的方法，或者将基于浏览器的应用程序集成到智能客户端应用程序的方法。
例如，智能客户端应用程序可以承载一个浏览器实例，这样就能够使用瘦客户端方法提供特定的内容和应用程序功能。当应用程序需要集成现有的瘦客户端应用程序，或者需要利用瘦客户端方法的某项关键性优势来提供 Web 服务器所提供的链接动态内容时，这种体系结构很有用。当然，这样的内容和功能仅当用户联机时才可用，但应用程序的智能客户端部分却可以在脱机时提供有用的功能，并在联机时以对瘦客户端功能的访问增强应用程序。
某些情况下，混合方法可用于扩展现有的瘦客户端应用程序，方法是在 Web 页面内承载智能客户端控件或组件。这些组件可以提供丰富的、具有优秀响应效果的用户界面以及特定的应用程序功能（如呈现和可视化数据），虽然应用程序的其余部分是按照瘦客户端的方式提供的。但是，这种体系结构不适用于提供脱机支持，原因是宿主 Web 页面在没有连接时不可用，它也不适用于提供软件或硬件的客户端集成，除非已经进行了适当的安全策略更改。
选择正确的交互层体系结构
很明显，瘦客户端和智能客户端方法分别有自己的功用。各种方法都各有优缺点，如何在它们之间选择有赖于特定应用程序的要求或业务需要。采用正确的方法，可以在充分考虑应用程序的开发、维护和运行等方面的同时，向用户提供良好的用户体验，使他们能够以有效和高效的方式与应用程序进行交互。
有些单位确立了对所有应用程序采用瘦客户端方法的策略。在默认情况下选择瘦客户端方法可能会对某些应用程序造成严重的技术问题，这是因为浏览器平台不能方便地支持中等复杂性的应用程序的要求。开发具有传统的胖客户端应用程序的外观、感觉和功能的瘦客户端应用程序，是一项极其困难而又代价高昂的工作。为什么呢？浏览器在状态管理、客户端逻辑、客户端数据和提供拖放、撤销/重复等胖用户界面功能方面，会对开发人员造成严重限制。相反，为所有应用程序选择智能客户端方法也不合适，这是因为它会导致为只是动态显示数据并需要高度动态用户界面的好处的应用程序采用过分复杂的解决方案。此外，如果您的应用程序必须支持多个客户端操作系统，则由于跨平台限制，智能客户端方法可能并不适用。
因此，对所有应用程序采用一种单一的方法可能会导致不必要的成本、复杂性、缺乏灵活性和可用性降低。视特定应用程序和业务的需要而定，两种方法可以在企业内共存。选择一种方法而不是另一种，应当分别就每个应用程序决定，当然，某些情况下两种方法可以结合使用，或者适当地集成瘦客户端和智能客户端技术，或者采用双通道方法，让某些用户使用瘦客户端访问应用程序，而让要求更严格的用户使用智能客户端。对于任一种方法，关键都是在适当的时候利用适当的技术，以满足用户的预期和业务的总体需要。
瘦客户端方法在易于获得以及部署和运行的便捷性方面享有众所周知的优势。但是，智能客户端技术到来后，智能客户端在这个方面正逐步缩小距离，现在已经在某些情况下成为瘦客户端的可行替换方案。特别是，智能客户端并没有胖客户端解决方案在部署和管理方面的问题，而在灵活性、响应效果和性能方面，智能客户端解决方案具有更强的优势。
那么，如果部署和可管理性不再是影响两种方法之间选择的决定性因素，我们又该如何进行选择？随着瘦客户端方法在这一领域的优势被逐渐削弱，平衡发生着变化，必须考虑的因素增多了。视要求的相对优先级而定，一种方法将比另一种更合适，而选择正确的方法带来的是更快和更简单的开发过程、更为简便的使用和更高的用户满意度。
前面介绍了各种方法的功能、优点和缺点，那么，在确定了特定应用程序的要求时，如何将以上信息应用到决策中？公司企业必须考虑的一些更为重要的因素包括：
| • | 客户端平台要求 |
| • | 部署和更新要求 |
| • | 用户体验要求 |
| • | 性能要求 |
| • | 客户端集成要求 |
| • | 脱机要求 |
以上并不是完整的因素列表，您公司的 IT 部门可能会添加对于特定应用程序至关重要的其他因素。特别是，这个因素列表主要关注的是运行或功能要求，而并不包括开发和设计时因素。而这些因素可能具有足够的重要性，足以颠覆一种方法与另一种方法之间的平衡。正确方法的确定，是 IT 人员和企业主的共同决定。所采用的方法应当产生一个使双方都满意的解决方案：管理方的 IT 部门，和功能方的企业主。
客户端平台
对于面向主要使用者位于单位外部的应用程序的客户或合作伙伴，或者对于不能规定使用特定客户端平台的客户或合作伙伴，或者必须从非 Windows 操作系统访问的应用程序来说，客户端平台灵活性可能非常重要。
瘦客户端提供了面向多种客户端平台运行的能力，虽然这通常要求应用程序确定目标平台的确切类型，以便它能够更改其运行或行为以适应各种浏览器之间的区别，特别是在目标平台必须包括移动设备时。瘦客户端框架本身可以处理许多这样的区别。例如，服务器上的 ASP.NET 可以确定目标浏览器的类型，并相应地为各种浏览器呈现内容。但是，如果使用其中一些更为高级的浏览器功能，将可能导致不得不开发特定的代码，以处理浏览器类型之间的区别。
智能客户端方法不提供这种功能，虽然仅面向 Windows 操作系统的应用程序可以使用 .NET Framework 和/或 .NET Compact Framework（对于移动应用程序）来基于各式各样的客户端设备（甚至向外部用户）提供智能客户端解决方案。
如果您的应用程序必须支持外部用户或者运行在非 Windows 操作系统上的客户端，那么应当优先考虑瘦客户端方法。
部署和更新
瘦客户端和智能客户端方法都需要将用户界面、应用程序逻辑和数据部署到客户端。两种情况下，这些部件都位于一个中央位置并集中管理，根据需要部署到客户端。在瘦客户端方法中，这些部件并不保存在客户端上，而需要在用户每次运行应用程序时进行“部署”。在智能客户端方法中，客户端可以保存这些部件以启用脱机使用，或者优化部署和更新过程。
由于两种方法都允许公司集中存放应用程序的部件，因此他们在用户授权、应用程序部署、更新等方面都提供了集中式管理。公司可以使用瘦客户端和智能客户端提供解决方案，以确保用户仅运行应用程序的最新版本，但是智能客户端可以实现附加的灵活性，如能够让不同的用户运行应用程序的不同版本（如试验组），或者让应用程序脱机运行。但是，要实现这些优势，解决方案可能需要进行附加的安全策略更改和/或在客户端部署一个更新管理器组件。
如果您的方案要求应用程序脱机运行，您应当优先考虑智能客户端方法。但是，如果在客户端上保存部件对应用程序没什么好处，那么采用瘦客户端方法可能更合理。后一种情况下，对于主要显示动态数据或者并发问题（对于应用程序逻辑或数据来说）可能较严重的应用程序，使用瘦客户端效果一般更佳。
用户体验
瘦客户端和智能客户端应用程序分别适用于特定的用户界面样式。许多瘦客户端应用程序都试图提供较丰富用户体验，但是由于浏览器（相对于智能客户端平台）的局限性，总是在某些重要的方面表现欠佳。例如，在瘦客户端解决方案中，基本的胖客户端功能（如拖放和撤销/重复）开发起来很困难。与提供这些功能相关联的复杂性可能相当高，并可能因此减损瘦客户端方法在跨平台方面的优势。
您还应当考虑用户与应用程序的交互方式。有些应用程序的线性很明了，这是因为用户通常以预定义或者类似的方式与它进行交互。其他应用程序则是非线性的，用户可以启动一个任务然后挂起，完成另一个任务，然后回到原先的任务。在瘦客户端解决方案中，管理提供这种功能所需状态可能非常具有挑战性。例如，如果用户在重要事务的过程中按下“返回”按钮，就必须将瘦客户端解决方案设计为能够处理这一状况。在智能客户端应用程序中，这种情况更容易处理。
智能客户端还可以利用本地资源来提供本地数据搜索、排序、可视化和客户端验证，从而提高应用程序的可用性，改善用户体验。这些功能可以提高数据质量、用户满意度和工作效率。
性能
这两种方法之间的一个重大区别是，相对于它的瘦客户端对手，智能客户端应用程序能够提供更高的性能。
就基础层面来说，瘦客户端通常使用脚本（瘦客户端必须在运行过程中解析脚本）作为提供和执行客户端应用程序逻辑的工具。与此相对，智能客户端解决方案可以向客户端提供特定的已编译代码。此外，也可能更为重要的是，智能客户端应用程序中的客户端逻辑在与用户界面、本地数据存储或者位于网络上的服务进行互动的方式方面受限更少。出于这些原因，好的智能客户端体系结构可以使解决方案开发人员能够更轻松地开发出高性能的解决方案。
用户对性能的感觉是由他们使用应用程序的方式和他们对应用程序行为的预期决定的。不常使用、或者用户并不与之进行很多互动的应用程序（如只是获取和显示数据的应用程序）并不能从更高的原始客户端性能获得多少好处。但是，对于使用频率很高的应用程序，即使常用的功能只有少许迟延，看上去都会显得性能很差。例如，在呼叫中心应用程序中，在检索客户订单详细信息时的四五秒钟的迟延，可以很轻易地累积为严重的用户不满（和高额成本）。
当然，对于在网络上发送或检索数据的功能，两种方法都会表现出相同的原始性能。但是，设计良好的智能客户端解决方案可以在一个单独的线程上执行其网络通讯，这使得应用程序能够在通过网络发送和接收数据时保持较好的响应能力。这样的后台工作可以主动完成，例如在对拨入的客户电话作出响应时。此外，智能客户端解决方案在本地缓存数据更为方便，而这可以降低网络调用的数量，或者降低执行同一功能所需的带宽。这些功能可以显著影响用户所感知到的应用程序的性能。
智能客户端解决方案可以提供更为严格的客户端数据验证。例如，由于智能客户端解决方案可以在本地缓存数据和逻辑，因此可以缓存只读的参考数据，而应用程序可以使用这些参考数据来提供域和交叉域验证。使用这种验证的应用程序可以较快地向用户提供反馈（从而提高被感知的应用程序性能），降低通过网络传输数据的次数，并确保更高的数据质量。瘦客户端解决方案可能需要依赖复杂的脚本来提供相同级别的功能，而对于没有在当前页面上显示的其他数据来说，可能无法在本地验证数据。
智能客户端解决方案还可以最大程度地利用本地处理、存储和显示功能，使用户可以在客户端上对数据进行查询、排序和可视化，而无需发出网络调用。在使用 Office 应用程序（如 Excel）作为智能客户端宿主环境时，这种能力表现特别突出。这可以显著降低瘦客户端应用程序执行同一功能所需的网络调用的数量。
由于智能客户端解决方案用户界面通常是由在客户端运行的特定代码提供的，因此它可以向用户提供响应更为迅捷的用户界面。胖客户端用户界面功能，如拖放、撤销/重复、上下文相关的帮助、键盘快捷方式等，都有助于改善用户体验以及被感知的应用程序性能。
如果性能是重要的问题，您应当考虑智能客户端解决方案。用户所感知的应用程序性能通常比各个操作的实际性能更为重要。好的应用程序的最终目标是确保在保持用户满意度的情况下，使用户能够有效和高效地执行他们的工作。
客户端集成
很多时候应用程序需要访问客户端资源，以便将它们集成到总体解决方案中。客户端资源有时包括硬件（打印机、电话、条形码识别器等）或软件（集成其他行业或桌面应用程序）。
当然，瘦客户端和智能客户端方法都在一个沙箱内运行。对于瘦客户端，浏览器提供了沙箱；对于智能客户端，.NET Framework 运行库提供了沙箱。将客户端资源集成到瘦客户端应用程序通常需要使用混合型应用程序体系结构，将组件（如 ActiveX 控件）承载到页面内，以便扩展到浏览器沙箱之外。这种方法不够灵活，通常要依靠用户来作出是否下载组件并在客户端上用户的登录帐户下运行的安全性决策。
.NET Framework 运行库采用了一个更为灵活的方法，根据它所提供的证据和本地安全策略来授予托管代码权限。默认情况下，从 Web 服务器下载的代码非以严格受限和特定的方式，不能与本地资源交互。但是，您的应用程序逻辑可以授予代码访问特定资源（如磁盘上的特定目录、对其他应用程序的访问、本地数据库等）的附加权限。
这种托管方法代表了一种在控制应用程序的安全性方面更为精细和更为灵活的机制，它使得智能客户端能够集成其他客户端资源，而不会带来安全风险。更为重要的是，由网络管理员而不是各个用户来使用安全策略作出安全性决策，这样应用程序代码就无法在没有得到授权的情况下执行操作或访问资源。
智能客户端应用程序常常使用代码访问安全性来控制在客户端上缓存数据和逻辑。这样的行为对于提供脱机功能非常重要，因此这些种类的应用程序通常要求进行安全策略更改来授予特定的权限。通常，这会涉及到授予应用程序在本地磁盘上缓存代码和数据的权限。如果解决方案需要访问客户端资源（如本地硬件或本地安装的其他应用程序），那么采用智能客户端方法将可以提供安全和灵活的解决方案。
脱机功能
各个单位越来越依赖它们的 IT 系统和这些系统提供的数据和服务，与此同时，用户进行脱机工作的能力也变得更为重要。提供对脱机访问数据和服务的支持，无论联机或是脱机都能使用相同的应用程序，用户将可以随时保持高效率的工作，同时有利于确保一致性和数据质量。
虽然网络连接正变得越来越普及，但是必须注意到光是具备网络连接通常并不能保证对应用程序和它所代表的数据和服务的访问。用户离开办公室后，可能无法访问防火墙内的商业应用程序，除非单位投资建置了 VPN 基础结构。即使在这种情况下，实现连接也既耗时又昂贵。对应用程序进行随意或者短暂的访问通常并不合理，或者可能导致失去商机或数据出现不一致。
有时，用户可以计划脱机时间。例如，您可能有一位销售人员要在外出差一段时间，或者有在家工作的用户。但是，有时计划脱机的情形很困难。例如，一位在商场内的用户可能有一台手写式 PC，而其无线连接会定期中断。另一个注意事项是用户的连接质量。随着众多单位在全球的分布越来越广，网络连接可能会因高迟延或者低带宽问题而遭受不利影响。
这些情况下，智能客户端解决方案都可以提供对应用程序的稳定访问，因此可以最小化或者消除连接变化的影响。通过在客户端上智能缓存数据和逻辑，并且在需要时自动向数据和逻辑部署更新，应用程序可以向用户提供无缝的体验，无论连接状态如何。此外，智能客户端可以确保所有的网络调用都在一个后台线程上处理，因此应用程序永远都不需要等待网络作出响应，这同样使得用户能够持续工作，而不管网络的状态怎样。
使用瘦客户端解决方案实现这些目标非常困难。有些解决方案试图通过使用本地 Web 服务器在客户端上提供 Web 应用程序或它的一个子集来解决这一问题。这样的解决方案很难维护，并需要复杂的基础结构来确保能够正确处理对应用程序及其数据的更新。这些解决方案削弱了集中式管理的优势，而这种优势正是常被用来支持采用瘦客户端解决方案的主要理由，而且它们会带来瘦客户端解决方案所先天具有的所有其他缺点。
小结
对于应用程序总体上的成功来说，选择正确的表示层体系结构可能是至关重要的。合适的体系结构可以在用户体验、开发与测试的便利以及应用程序的运行要求之间达致一个适当的均衡。用户越来越要求更多考虑他们的利益。
瘦客户端和智能客户端方法都分别适用于特定样式的应用程序。最近的一些技术进步矫正了这些方法之间的不均衡，使得它们无需被错误地应用到并不适用它们的情况。从一开始就应用正确的方法非常重要，非此无以避免不必要的复杂性、高额成本、缺乏灵活性和较差的用户体验。
偏重两种方法中其中一种的一边倒的企业策略很容易导致这些问题。任何单位都必须审慎考虑应用程序的总体需要，并将之与各种方法的功能进行比较。可能影响这一决策的因素很多并且种类多样，本文仅介绍了其中一些更为常见的因素。无论如何，这一决策最终都是各种因素之间的一个妥协。理解这些因素和它们的相对优先级，有助于确保您的单位选择正确的表示层体系结构。
资源
| • | Smart Client Architecture and Design Guide - Microsoft Patterns and Practices. |
| • | Overview of Office 2003 Developer Technologies - MSDN. |
| • | Overview of Office 2003 Developer Tools and Programs - MSDN. |
