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