1.1  为什么需要Ajax富客户端？

建造一个富客户端[2]毫无疑问要比设计一个网页复杂。付出这些额外的努力，动机何在？需要付出什么代价？而且……等一下，富客户端到底是什么？

富客户端的两个要点是：第一，它是“富”的；第二，它是“客户端”。

这好像是一句废话，别急，待我稍作解释。“富”是指客户端的交互模型，要有多样化的输入方式和符合直觉的及时反馈手段。说简单点儿，一个“富”的应用使用起来应该像是在使用现在的桌面应用一样，例如，就像是使用字处理软件（Word）或电子表格软件（Excel）。接下来，我们有必要仔细地考察一下所要涉及的各个方面。

1.1.1  比较用户体验

花几分钟使用一下你选中的应用（浏览器除外），记下它用到了哪些用户交互，然后马上回来。为了简短起见，我举一个电子表格的例子，但是，这里所涉及的要点是通用的，足以针对文本编辑器上的各种情形。

好，我们开始。先在电子表格中随便输入几个等式，注意到，可以以几种方式进行交互：编辑数据，用键盘和鼠标浏览数据，还可以使用鼠标拖拽来重新组织数据。

我做这些操作的时候，程序给了我反馈。移动鼠标的时候，光标改变了形状；当鼠标停在上面的时候，按钮变亮了；选中的文字也改变了颜色。窗口或者对话框被选中的时候，也和平常显得不一样了，等等（图1-1）。这些就是所谓“富”的交互。当然了，仍然有一些有待改进的地方，但这是一个好的开始。

OK，电子表格就是一个富客户端程序了吗？当然不是。

在电子表格或者类似的桌面应用中，业务逻辑和数据模型是在一个封闭的环境中运行的。在这个环境中，它们彼此清晰地了解对方，并且可以互相访问，而环境之外的东西，对于它们来说是未知的（图1-2）。那么客户端又是什么呢？它是与另一个独立的进程相互通信的程序，后者通常运行在服务器上。一般来说，服务器总是要比客户端大一些，能力强一些，配置更好一些，因为在服务器上通常要存储浩如烟海的信息。客户端程序使得最终用户可以查看和修改这些信息，当多个客户端连接在同一个服务器上的时候，可以在它们之间共享这些信息。图1-3展示了一个简单的客户/服务器架构。

图1-1  这个桌面电子表格应用展现了用户交互的众多可能性。被选中单元格的行列标题都是突出显示的；按钮在鼠标移上去的时候会显示提示信息；工具栏上排列着各种丰富的控件；单元格也可以交互地查看和编辑

图1-2  一个独立的桌面应用的架构示意图。应用运行在它自己的独立进程之中，数据模型和程序逻辑能够彼此“看到”对方的存在。除了通过文件系统之外，同一个应用的第二个运行实例[3]没有办法访问到第一个运行实例的数据模型。通常来说，整个程序的状态都保存在单个文件中，当应用运行的时候，这个文件会被加锁以阻止其他的进程同时访问

图1-3  客户/服务器系统和n层架构的示意图。服务器提供了共享的数据模型，客户端与该数据模型交互。客户端同时还维护数据模型的一部分，以获得快速的访问，但是它将服务器端的模型当作业务领域对象的最终表示。多个客户端可以与同一个服务器交互，当然，这需要有合适的资源锁定机制和合理的对象（或者数据行）隔离措施作为保证。服务器可以是单进程的，就像在20世纪90年代早期和中期传统的客户/服务器模型中一样，也可以是由很多个中间件层或者多个Web服务等组成。在任何一种情况下，从客户端的角度来看，服务器都有一个单独的接入点，可以看作是一个黑盒

在现代的n层架构中，服务器往往要和更远的后端服务器（例如数据库）通信，因此被称作“中间件”的层同时扮演着客户端和服务器的角色。我们的Ajax应用位于这个链的一端，它仅仅是作为客户端，因此为讨论方便，我们可以把整个n层系统看作是一个标记为“服务器”的黑盒。

我的电子表格应用只需要管理它自己保存在内存或本地文件系统中的少量数据。如果架构设计良好的话，数据和它的表现形式的耦合可以非常松散，但是我不能通过网络来分割或者通过网络来共享它们。从这个意义上来说，电子表格应用不是一个客户端。

与之相对应的Web浏览器就是一个典型的客户端，它与Web服务器通信，请求需要的页面。浏览器有丰富的功能，用来管理用户的浏览行为，常见功能有回退按钮、历史列表和分页浏览多个文档等等。但是当我们把特定网站的Web页面看作是一个应用时，这些通用的浏览功能实际上和应用关系不大，充其量也就如电子表格和Windows的开始按钮或者窗口列表之间的关系。

我们来考察一下现代的Web应用。为了简单起见，我们选择了“地球人都知道”的在线书店Amazon.com（图1-4）。在浏览器中打开Amazon网站，因为在此之前我访问过，它会给我显示一个友好的问候、一些推荐书目，还有我的购买历史信息。

点击推荐书目中的任何一条，就会转到另外一个页面（此时，页面要刷新一下，在这几秒钟内我什么也看不到）。新页面是该书的相关信息：书评、二手书报价、同一作者的其他著作，以及以前我浏览过的其他书籍（图1-5）。

图1-4  Amazon.com的首页。系统记得我上一次的访问。导航链接除了通用模板文件，还有个性化信息

图1-5  Amazon.com书籍详细信息的页面。包括一大堆通用信息和个性化信息的超链接。虽说其中的大量内容和图1-4中的一模一样，但是由于Web浏览器使用基于文档的操作，每次发送新页面都必须要重新发送这些内容

简而言之，呈现在我面前的是非常丰富的、关联度很高的信息。但是对我而言，交互的方式就是点击那些超链接，然后填写一些表格。假设我在键盘前面不小心睡着了，第二天才醒来，如果不刷新页面，我就没法知道《哈里·波特》系列的新书已经出版了，也不能将我的列表从一个页面带到另一个页面，我要是想同时看到更多一些东西也不行，因为我无法改变页面上局部内容区域的大小。

我似乎是在批评Amazon的界面，其实并非如此，我只是拿它来做个例子。事实上，在传统Web开发方式的桎梏下，他们已经做得非常棒了。但是比起电子表格来说，它所用的交互模型毫无疑问是太有限了。

为何现代的Web应用仍然有这么多的局限呢？造成目前的状况有一些合理的技术原因，我们现在就来考察一下。

1.1.2  网络延迟

因特网的宏伟蓝图是将这个世界上所有的计算机都连接起来，形成一个无比巨大的计算资源。如果能把本地调用和远程调用等同起来，那么无论是分析蛋白质的成分还是破解外太空的信号，使用者都无需考虑机器的物理位置，剩下来的只有愉快地计算。

但是非常不幸，本地调用和远程调用是完全不同的东西。在现有的技术水平之下，网络通信仍然是一件代价高昂的事情（也就是说，通常很慢，而且并不可靠）。在没有网络调用的情况中，不同的方法和函数以及它们所操作的数据都位于相同的本地内存中（图1-6），向方法内传递数据并且获得方法的返回结果是非常直接的。

图1-6  本地过程调用的顺序图。参与者很少，因为程序逻辑与数
   据模型都保存在本地内存中，并且彼此可以直接访问

而在有远程调用的情况下，位于网络两端的通信双方为了发送和接收数据在底层需要进行大量计算（图1-7）。比起数据在线路上的往返，这些计算需要消耗更多的时间。传输一段二进制的数据，中间要经过很多环节的编码和解码、错误校验、失败重发、数据包拆分和重组，数据最终转化为0和1表示的二进制信号，通过线路（或者无线连接）到达另外一方。

在本地，调用函数的调用请求被编码为一个对象，然后将这个对象序列化为一系列字节，最后使用应用层协议（通常是HTTP）通过物理传输介质（例如铜缆、光纤或者无线电波）将其发送出去。

在远程机器上，对应用层协议解码，将获得的数据字节反序列化，创建一个请求对象的副本。然后对数据模型应用这个对象并生成一个响应对象。为了将响应对象传递给本地的调用函数，所有的序列化、反序列化以及传输层的操作都要反向再来一次。最后，响应对象被传递给本地的调用函数。

图1-7  远程过程调用的顺序图。一台机器的程序逻辑尝试操作另外一台机器上的数据模型

这个交互过程很复杂吧，幸好，它是可以自动完成的。现代的编程环境如Java和Microsoft的.NET框架都内置了这个能力。尽管如此，执行远程调用时，上述所有这些操作仍然会在内部执行。如果我们到处使用远程调用，性能势必会大受影响。

这也就是说，远程调用是不可能和本地调用一样有效率的。更糟糕的是，网络的不稳定更让这种效率损失捉摸不定，难以预计。相比之下，运行在本地内存之中的本地调用，在这一点上无疑要有优势得多。

等等，说了半天的远程调用，这和软件的可用性有关系吗？答案是，大有关系。

一个成功的计算机用户界面要能以最起码的水平模拟我们在真实世界中的体验。交互的基本规则之一就是，当我们推一下、刺一下或者捅一下某个东西的时候，它立刻就会响应。响应的时间只要稍微拖长一点点，就会使人困惑，分散其注意力，把关注点从手头的任务转移到用户界面上。

远程调用横穿整个网络，需要执行大量的额外操作，它们往往会把系统拖慢，使用户察觉到延迟。在桌面应用中，只有当可用性设计做得非常糟糕的时候，才会出现这种令用户感觉充满bug、反应迟钝的用户界面，但在网络应用中，什么都不做就能得到大量这样的界面。

因为网络延迟不可预测，这类界面问题往往都神出鬼没，对应用响应的测试也难以开展。换句话说，网络延迟是导致实际应用的交互性糟糕的一个普遍原因。

1.1.3  异步交互

用户界面的开发者对于网络延迟只能做最坏的假设。简单地说，就是要尽可能让用户界面与网络活动无关。天才的程序员们早已发明了一种确实有效而且久经考验的方案，来专门解决这一问题。先卖个关子，让我们到现实世界中走一趟。

在我每天早上必做的事中，很重要的一项是叫醒我的孩子去上学。我可以站在床边把他们折腾醒，催着他们起床穿衣，但这是一种很耗费时间的方法，总要耗费我很多宝贵的早间时光（图1-8）。

图1-8  在我每日早晨必做的事中，以同步方式响应用户输入的顺序图。顺序图中纵向表示时间的流逝，其中的阴影区域表示了我被阻塞不能接受其他输入的时间长度

我要叫醒孩子，看看窗外，往往会忽略了喂猫。孩子们起来之后会问我要早餐。就像服务器端的进程一样，孩子们起床总是慢吞吞的。如果我遵循同步交互模式，就要等他们老半天。不过，只要他们嘟囔一句“我醒了”，我就可以先去干其他的事，需要时再回来看看他们。

按照计算机的术语，我需要做的就是为每个孩子在一个单独的线程中建立一个异步进程。开始之后，孩子们会在他们的线程里自己起床，我这个父线程没有必要同步傻等，他们完事后会通知我（往往还会问我要吃的）。在他们醒来的过程中，我并不需要和他们交互，就当他们已经起来并自己穿好衣服了，因为我有理由相信他们很快会这么做的（图1-9）。

对于任何用户界面来说，这是一种沿用已久的实践，即创建异步的线程，让它在后台处理那些需要计算很久的任务，这样用户可以继续做其他的事情。当启动这个线程的时候，有必要阻塞用户的操作[4]，但是在可接受的很短时间之后，阻塞就会解除。因为存在网络延迟，使用异步方式来处理任何耗时的远程调用是一种很好的实践。

图1-9  以异步方式响应用户输入的顺序图。如果遵循异步的输入模式，我可以让孩子们在醒来的时候通知我。在他们缓慢的起床过程中，我可以继续从事其他活动，这使得我被阻塞的时间大大缩短

实际上，网络延迟问题和相关的解决方案由来已久。在老的客户/服务器模式中，当设计不佳的客户端程序碰上了高负载的服务器时，用户界面就会出现让人难以忍受的延迟。即便是在如今的因特网时代，当切换页面时，如果浏览器半天出不来东西，那么这种糟糕的情况很可能就是因为网络延迟造成的。在现有技术条件下，我们暂时还没有办法消除网络延迟，但是至少有一个对策，那就是采用异步方式处理远程调用，不是吗？

糟糕的是，对于Web开发人员而言这样做存在一个难点：HTTP协议是一个“请求—响应”模式的协议。也就是说，客户端请求一个文档，服务器要么返回这个文档，要么告诉客户端找不着文档或者让客户端去另外一个地方找，还可以告诉客户端可以使用它的本地缓存，诸如此类。总而言之，“请求—响应”模式的协议是一种单向的通信协议。客户端可以向服务器发起连接，但是服务器不可以向客户端发起连接。甚至，当客户端下次发起通信请求时，健忘的服务器都记不起来这个客户端是谁了（HTTP是无连接的）。

多数Web开发者使用现代的编程语言，例如，Java、PHP或者.NET，他们熟悉用户会话（user session）的概念，这其实是应用服务器对于不能保持连接状态的HTTP协议的一种补救措施。HTTP就其最初的设计目的来说表现得非常好，采用一些巧妙的处理，它能够适应设计之初没有考虑的场合。但是我们的这个异步回调方案中的关键特征是，客户端会收到两次通知，一次是在线程创建的时候，另一次是在线程结束的时候。标准的HTTP和传统Web应用模型可不会提供这些。

像Amazon那样的传统Web应用，是建造在页面概念之上的。给用户显示一个文档，上面包括各种链接和表单，用户可进一步访问更多的文档。这种交互模式可以在很大的规模上支持复杂的数据集（就像Amazon和其他网站已经证明的那样），它所提供的用户体验也足以满足开展业务的需要。

十年来，这种交互模式在我们对因特网商业应用的看法上打下了深深的烙印。界面友好的所见即所得（WYSIWYG）Web制作工具使得站点更容易被理解为一堆页面。服务器端的Web框架使用状态图来对页面的转换建模。没有引入，传统的Web应用就这么一直牢牢地束缚在页面刷新操作之上，就好像这种刷新是理所当然而且无可避免的，从没有尝试过任何异步的处理方案。

当然，毫无疑问，传统的Web应用肯定不是一无是处的。毕竟Amazon在这种交互模式上创造了成功的商业应用。但是这种适用于Amazon的方式并不一定适用于所有的人。为什么这么说呢？要理解这一点，我们需要考察用户的使用模式（usage pattern）。

1.1.4  独占或瞬态的使用模式

泛泛地讨论自行车和SUV（运动型轿车）孰优孰劣毫无意义。因为它们各自都有优点和缺点——舒适度、速度、油耗或者个人身份的象征等等。只有在特定的使用模式下讨论，这样的比较才有意义。例如，是要在上下班高峰时段穿越市中心，还是要带上一家老小去度假，或者只是要找个躲雨的地方。在类似这样的具体情况下，我们才能有的放矢地比较。对于用户界面，亦复如是。

软件可用性专家Alan Cooper写了很多有关使用模式的好文章，他定义了两种主要的使用方式：瞬态的（transient）和独占的（sovereign）[5]。瞬态应用可能每天都会偶尔使用一下，但是总是作为次要的活动，突发性地用上一会儿。与之形成鲜明对比的是独占应用，独占应用需要应付用户每天几个小时的持续使用。

很多应用天生就具备独占或者瞬态的性质。例如，写作用的字处理软件就是一个独占应用，可能还会用到几个瞬态的应用，比如文件管理（文件的开启和关闭窗口中常常会嵌入这个功能）、字典或者拼写检查工具（很多字处理程序也嵌入这些功能），还有与同事联络的电子邮件和聊天工具。而对于软件开发者，文本编辑器、调试器或者IDE（集成开发环境）则是独占的。

独占应用常常使用得更频繁。要知道，一个良好的用户界面应该是不可见的。衡量使用频繁程度的一个好的标尺，是当这个用户界面发生明显的停顿时，它对于用户流程的影响。例如，从一个目录向另一个目录移动文件要发生2秒钟的停顿，我能愉快地接受；可是如果这两秒是发生在我正饱含激情地用绘画软件创作一幅作品时，或者是我正努力地调试一段很难对付的代码时，这肯定会让我感觉十分不爽。

Amazon是一个瞬态应用，eBay、Google以及大多数大型的公众Web应用都是瞬态应用。自因特网诞生之日起，专家们就曾经预测传统的桌面应用面临Web应用的冲击。十年过去了，这些都还没有发生，为什么呢？基于Web页面的方案对于瞬态应用是足够了，但是对于独占应用却还远远不够。

1.1.5  忘掉Web

现代Web浏览器和它最原始的出发点（从远程服务器上获得一个文档）相比已经完全不是一码事了，它们之间就像是瑞士军刀和新石器时代的狩猎工具一样，可谓是天壤之别。各种交互组件、脚本语言和插件，这些年来无法抑制地疯狂发展，近乎强制地一次又一次地创造着新的浏览体验。[可以到www.webhistory.org/www.lists/wwwtalk.1993q1/0182.html瞻仰一下浏览器的史前时代。1993年的时候，Netscape创立之前的Marc Andreessen（Netscape的创始人）还在游说Tim Berners-Lee（Web的创始人，W3C的领导者）等人，列举为HTML引入一个图片标签的好处]。

几年以前，一些先行者就已经开始把JavaScript当作一种严肃的编程语言来对待。但就整体而言，更多的人仍然把它和那些假模假样的警告框以及“点击猴子赢大奖”的广告一类的小把戏联系在一起。

浏览器大战导致JavaScript成了个被误解的、病态的孩子，Ajax可以看作是他的康复中心[6]。只要适当引导，然后给它配上合适的框架，JavaScript就很有可能变成因特网的模范公民。它能真正增强Web应用的实用性，而且不强迫用户安装额外的软件，或者逼迫用户抛弃自己心爱的浏览器。得到广泛理解的成熟的工具可以帮助我们达成这一目标。本书后面会大量提到的设计模式就是这样一类工具。

推广和普及一项新技术，既是技术事务，也是社会行为。一旦技术已经成熟，人们还需要领会应该如何去使用它。这一步骤常常是通过用它来做我们很熟悉的事情开始的。比如，早年的自行车叫做“木马轮”或者“蹬行马”，靠脚使劲蹬地的反作用力来前进。随着这一技术渐渐为大众所接受，后来的发明者们会发明出这一技术新的使用方式，给它加上踏板、刹车、链条齿轮以及充气轮胎。每一次的发明创造，都使得自行车中马的影子越来越淡，以至于彻底消失（图1-10）。

相同的过程也发生在如今的Web开发领域。Ajax背后的技术有能力将Web页面转换成某种完全不同的新东西。早期Ajax的使用尝试使得Web页面开始变得像“木马轮”一样不伦不类。要领悟Ajax的精髓，我们就要忘掉Web的页面概念，也就是说，我们要打破这些年来所形成的经验。就在Ajax正式命名后的这几个月，这样的事已经发生了不少。

图1-10  现代自行车的发展