这种效率损失捉摸不定,难以预计。相比之下,运行在本地内存之中的本地调用,在这一点 上无疑要有优势得多 等等,说了半天的远程调用,这和软件的可用性有关系吗?答案是,大有关系 个成功的计算机用户界面要能以最起码的水平模拟我们在真实世界中的体验。交互的基本 规则之一就是,当我们推一下、刺一下或者捅一下某个东西的时候,它立刻就会响应。响应 的时间只要稍微拖长一点点,就会使人困惑,分散其注意力,把关注点从手头的任务转移到 用户界面上。 远程调用横穿整个网络,需要执行大量的额外操作,它们往往会把系统拖慢,使用户察觉到 延迟。在桌面应用中,只有当可用性设计做得非常糟糕的时候,才会出现这种令用户感觉充 满bug、反应迟钝的用户界面,但在网络应用中,什么都不做就能得到大量这样的界面 因为网络延迟不可预测,这类界面问题往往都神出鬼没,对应用响应的测试也难以开展。换 句话说,网络延迟是导致实际应用的交互性糟糕的一个普遍原因。 1.1.3异步交互 用户界面的开发者对于网络延迟只能做最坏的假设。简单地说,就是要尽可能让用户界面与 网络活动无关。天才的程序员们早已发明了一种确实有效而且久经考验的方案,来专门解决 这一问题。先卖个关子,让我们到现实世界中走一趟。 在我每天早上必做的事中,很重要的一项是叫醒我的孩子去上学。我可以站在床边把他们折 腾醒,催着他们起床穿衣,但这是一种很耗费时间的方法,总要耗费我很多宝贵的早间时光 (图1-8) 唾的孩于 待哺 1.唉醒 2.慢慢醒来 3.通知 4.凝望窗外 5.态了服蘅 图1-8在我每日早晨必做的事中,以同步方式响应用户输入的顺序图。顺序图中纵向表示 时间的流逝,其中的阴影区域表示了我被阻塞不能接受其他输入的时间长度 我要叫醒孩子,看看窗外,往往会忽略了喂猫。孩子们起来之后会问我要早餐。就像服务器 端的进程一样,孩子们起床总是慢吞吞的。如果我遵循同步交互模式,就要等他们老半天ε 不过,只要他们嘟囔一句“我醒了”,我就可以先去干其他的事,需要时再回来看看他们。 按照计算机的术语,我需要做的就是为每个孩子在一个单独的线程中建立一个异步进程。开 始之后,孩子们会在他们的线程里自己起床,我这个父线程没有必要同步傻等,他们完事后 会通知我(往往还会问我要吃的)。在他们醒来的过程中,我并不需要和他们交互,就当他
这种效率损失捉摸不定，难以预计。相比之下，运行在本地内存之中的本地调用，在这一点 上无疑要有优势得多。 等等，说了半天的远程调用，这和软件的可用性有关系吗？答案是，大有关系。 一个成功的计算机用户界面要能以最起码的水平模拟我们在真实世界中的体验。交互的基本 规则之一就是，当我们推一下、刺一下或者捅一下某个东西的时候，它立刻就会响应。响应 的时间只要稍微拖长一点点，就会使人困惑，分散其注意力，把关注点从手头的任务转移到 用户界面上。 远程调用横穿整个网络，需要执行大量的额外操作，它们往往会把系统拖慢，使用户察觉到 延迟。在桌面应用中，只有当可用性设计做得非常糟糕的时候，才会出现这种令用户感觉充 满 bug、反应迟钝的用户界面，但在网络应用中，什么都不做就能得到大量这样的界面。 因为网络延迟不可预测，这类界面问题往往都神出鬼没，对应用响应的测试也难以开展。换 句话说，网络延迟是导致实际应用的交互性糟糕的一个普遍原因。 1.1.3 异步交互 用户界面的开发者对于网络延迟只能做最坏的假设。简单地说，就是要尽可能让用户界面与 网络活动无关。天才的程序员们早已发明了一种确实有效而且久经考验的方案，来专门解决 这一问题。先卖个关子，让我们到现实世界中走一趟。 在我每天早上必做的事中，很重要的一项是叫醒我的孩子去上学。我可以站在床边把他们折 腾醒，催着他们起床穿衣，但这是一种很耗费时间的方法，总要耗费我很多宝贵的早间时光 （图 1-8）。 图 1-8 在我每日早晨必做的事中，以同步方式响应用户输入的顺序图。顺序图中纵向表示 时间的流逝，其中的阴影区域表示了我被阻塞不能接受其他输入的时间长度 我要叫醒孩子，看看窗外，往往会忽略了喂猫。孩子们起来之后会问我要早餐。就像服务器 端的进程一样，孩子们起床总是慢吞吞的。如果我遵循同步交互模式，就要等他们老半天。 不过，只要他们嘟囔一句“我醒了”，我就可以先去干其他的事，需要时再回来看看他们。 按照计算机的术语，我需要做的就是为每个孩子在一个单独的线程中建立一个异步进程。开 始之后，孩子们会在他们的线程里自己起床，我这个父线程没有必要同步傻等，他们完事后 会通知我（往往还会问我要吃的）。在他们醒来的过程中，我并不需要和他们交互，就当他
们已经起来并自己穿好衣服了,因为我有理由相信他们很快会这么做的(图1-9)。 对于任何用户界面来说,这是一种沿用已久的实践,即创建异步的线程,让它在后台处理那 些需要计算很久的任务,这样用户可以继续做其他的事情。当启动这个线程的时候,有必要 阻塞用户的操作[4],但是在可接受的很短时间之后,阻塞就会解除。因为存在网络延迟 使用异步方式来处理任何耗时的远程调用是一种很好的实践。 唾的接子 紲件哺 1.啖醒 3.极醒来 4.凝望窗外 5.忘了喂葡 6.通知 图1-9以异步方式响应用户输入的顺序图。如果遵循异步的输入模式,我可以让孩子们在 醒来的时候通知我。在他们缓慢的起床过程中,我可以继续从事其他活动,这使得我被阻塞 的时间大大缩短 实际上,网络延迟问题和相关的解决方案由来已久。在老的客户/服务器模式中,当设计不 佳的客户端程序碰上了高负载的服务器时,用户界面就会出现让人难以忍受的延迟。即便是 在如今的因特网时代,当切换页面时,如果浏览器半天出不来东西,那么这种糟糕的情况很 可能就是因为网络延迟造成的。在现有技术条件下,我们暂时还没有办法消除网络延迟,但 是至少有一个对策,那就是采用异步方式处理远程调用,不是吗? 糟糕的是,对于Web开发人员而言这样做存在一个难点:HIIP协议是一个“请求一响应” 模式的协议。也就是说,客户端请求一个文档,服务器要么返回这个文档,要么告诉客户端 找不着文档或者让客户端去另外一个地方找,还可以告诉客户端可以使用它的本地缓存,诸 如此类。总而言之,“请求一响应”模式的协议是一种单向的通信协议。客户端可以向服务 器发起连接,但是服务器不可以向客户端发起连接。甚至,当客户端下次发起通信请求时, 健忘的服务器都记不起来这个客户端是谁了(HTIP是无连接的) 多数web开发者使用现代的编程语言,例如,Java、PHP或者NET,他们熟 悉用户会话(usersession)的概念,这其实是应用服务器对于不能保持连接状态的HTTP协 议的一种补救措施。HITP就其最初的设计目的来说表现得非常好,采用一些巧妙的处理, 它能够适应设计之初没有考虑的场合。但是我们的这个异步回调方案中的关键特征是,客户 端会收到两次通知,一次是在线程创建的时候,另一次是在线程结束的时候。标准的HTIP 和传统Web应用模型可不会提供这些 像 Amazon那样的传统web应用,是建造在页面概念之上的。给用户显示一个文档,上面 包括各种链接和表单,用户可进一步访问更多的文档。这种交互模式可以在很大的规模上支 持复杂的数据集(就像 Amazon和其他网站已经证明的那样),它所提供的用户体验也足以
们已经起来并自己穿好衣服了，因为我有理由相信他们很快会这么做的（图 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/0182hm瞻仰一下 浏览器的史前时代。1993年的时候, Netscape创立之前的 Marc Andreessen( Netscape的创 始人)还在游说 Tim berners-lee(web的创始人,W3C的领导者)等人,列举为HTML引 入一个图片标签的好处]。 几年以前,一些先行者就已经开始把 JavaScript当作一种严肃的编程语言来对待。但就整体 而言,更多的人仍然把它和那些假模假样的警告框以及“点击猴子赢大奖”的广告一类的小
满足开展业务的需要。 十年来，这种交互模式在我们对因特网商业应用的看法上打下了深深的烙印。界面友好的所 见即所得（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现代自行车的发展 12Ajax的四个基本原则 我们用到的很多框架中都已经固化了基于页面的传统应用模式,同时这些应用模式也已经深 深进入了我们的思想中。我们花几分钟来揭示出哪些核心概念是我们需要重新思考的,以及 如何从Ajax的角度来重新思考。 21浏览器中的是应用而不是内容 在传统的基于页面的web应用中,浏览器扮演着哑终端[刁]的角色。它对用户处于操作流程 哪一阶段一无所知。这些信息全部都保存在服务器上,确切地说,就是在用户会话上。时至 今日,服务器端的用户会话早已是司空见惯。如果你使用Java或者NET编程,服务器端的 用户会话更是标准AP的一部分——还有 Request、 Response、MME类型—一没有了它们 简直不可想象。图1-11描绘了传统Web应用典型的生命周期 当用户登录或者以其他方式初始化一个会话时,系统会创建几个服务器端的对象。例如,电 子商务类型的网站需要创建表示购物车以及用户身份证明的对象。同时将浏览器站点的首页 呈现给用户,这个HIML标记的数据流由模板文件以及特定于该用户的数据和内容(例如 该用户最近浏览的商品列表)组成。 用户每次和服务器交互,都会获得另一个文档。在这个文档中,除了特定于该用户的数据以 外,包含的其他模板文件和数据都是相同的。浏览器总是忠实地丢弃掉老的文档,显示新的 文档,因为它是哑终端,而且也不知道还可以做些什么。 当用户选择退出或者关闭浏览器的时候,应用退出,会话消失。这个时候持久层会把用户下 次登录后需要显示的信息存储起来。Ajax则不同,它把一部分应用逻辑从服务器端移到了 浏览器端,图1-12描绘了这一情况
把戏联系在一起。 浏览器大战导致 JavaScript 成了个被误解的、病态的孩子，Ajax 可以看作是他的康复中心[6]。 只要适当引导，然后给它配上合适的框架，JavaScript 就很有可能变成因特网的模范公民。 它能真正增强 Web 应用的实用性，而且不强迫用户安装额外的软件，或者逼迫用户抛弃自 己心爱的浏览器。得到广泛理解的成熟的工具可以帮助我们达成这一目标。本书后面会大量 提到的设计模式就是这样一类工具。 推广和普及一项新技术，既是技术事务，也是社会行为。一旦技术已经成熟，人们还需要领 会应该如何去使用它。这一步骤常常是通过用它来做我们很熟悉的事情开始的。比如，早年 的自行车叫做“木马轮”或者“蹬行马”，靠脚使劲蹬地的反作用力来前进。随着这一技术 渐渐为大众所接受，后来的发明者们会发明出这一技术新的使用方式，给它加上踏板、刹车、 链条齿轮以及充气轮胎。每一次的发明创造，都使得自行车中马的影子越来越淡，以至于彻 底消失（图 1-10）。 相同的过程也发生在如今的 Web 开发领域。Ajax 背后的技术有能力将 Web 页面转换成某种 完全不同的新东西。早期 Ajax 的使用尝试使得 Web 页面开始变得像“木马轮”一样不伦不 类。要领悟 Ajax 的精髓，我们就要忘掉 Web 的页面概念，也就是说，我们要打破这些年来 所形成的经验。就在 Ajax 正式命名后的这几个月，这样的事已经发生了不少。 图 1-10 现代自行车的发展 1.2 Ajax 的四个基本原则 我们用到的很多框架中都已经固化了基于页面的传统应用模式，同时这些应用模式也已经深 深进入了我们的思想中。我们花几分钟来揭示出哪些核心概念是我们需要重新思考的，以及 如何从 Ajax 的角度来重新思考。 1.2.1 浏览器中的是应用而不是内容 在传统的基于页面的 Web 应用中，浏览器扮演着哑终端[7]的角色。它对用户处于操作流程 哪一阶段一无所知。这些信息全部都保存在服务器上，确切地说，就是在用户会话上。时至 今日，服务器端的用户会话早已是司空见惯。如果你使用 Java 或者.NET 编程，服务器端的 用户会话更是标准 API 的一部分——还有 Request、Response、MIME 类型——没有了它们 简直不可想象。图 1-11 描绘了传统 Web 应用典型的生命周期。 当用户登录或者以其他方式初始化一个会话时，系统会创建几个服务器端的对象。例如，电 子商务类型的网站需要创建表示购物车以及用户身份证明的对象。同时将浏览器站点的首页 呈现给用户，这个 HTML 标记的数据流由模板文件以及特定于该用户的数据和内容（例如 该用户最近浏览的商品列表）组成。 用户每次和服务器交互，都会获得另一个文档。在这个文档中，除了特定于该用户的数据以 外，包含的其他模板文件和数据都是相同的。浏览器总是忠实地丢弃掉老的文档，显示新的 文档，因为它是哑终端，而且也不知道还可以做些什么。 当用户选择退出或者关闭浏览器的时候，应用退出，会话消失。这个时候持久层会把用户下 次登录后需要显示的信息存储起来。Ajax 则不同，它把一部分应用逻辑从服务器端移到了 浏览器端，图 1-12 描绘了这一情况
W闪览 用产 Web页面 共享数 据模型 图1-11传统Web应用的生命周期。用户和应用会话的所有状态都保留在Web服务器上。 用户在会话中看到的是一系列的页面,每次页面切换都不可避免地要到服务器上走一个来回 图1-12Ajax应用的生命周期。用户登录后,服务器交付一个客户端应用给浏览器。这个应 用可以独立处理很多的用户交互,对于自己无法独立处理的交互,应用会以后台方式发送请 求给服务器,而不会打断用户的操作流程 用户登录的时候,服务器交付给浏览器一个复杂得多的文档,其中包含大量的 JavaScript代 码。这个文档将会在整个会话的生命周期内与用户相伴。在这一过程中,随着用户与其交互, 它的外观可能会发生相当大的变化。它知道如何响应用户的输入,能够决定对于这些请求, 是自行处理还是传递给web服务器(web服务器再去访问数据库或者其他资源),或者通过 两者结合的方式进行处理 因为这个文档在整个用户会话中都存在,所以它可以保存状态[8]。例如,购物车的内容可 以保存在浏览器中而不是服务器的会话中 务器 e2s 果户的分L应月的 效据横型 据械型 J心sa中?频案的激 客户端应用 合语 退出页而 共享嫩 怩模型 12.2服务器交付的是数据而不是内容
图 1-11 传统 Web 应用的生命周期。用户和应用会话的所有状态都保留在 Web 服务器上。 用户在会话中看到的是一系列的页面，每次页面切换都不可避免地要到服务器上走一个来回 图 1-12 Ajax 应用的生命周期。用户登录后，服务器交付一个客户端应用给浏览器。这个应 用可以独立处理很多的用户交互，对于自己无法独立处理的交互，应用会以后台方式发送请 求给服务器，而不会打断用户的操作流程 用户登录的时候，服务器交付给浏览器一个复杂得多的文档，其中包含大量的 JavaScript 代 码。这个文档将会在整个会话的生命周期内与用户相伴。在这一过程中，随着用户与其交互， 它的外观可能会发生相当大的变化。它知道如何响应用户的输入，能够决定对于这些请求， 是自行处理还是传递给 Web 服务器（Web 服务器再去访问数据库或者其他资源），或者通过 两者结合的方式进行处理。 因为这个文档在整个用户会话中都存在，所以它可以保存状态[8]。例如，购物车的内容可 以保存在浏览器中而不是服务器的会话中。 1.2.2 服务器交付的是数据而不是内容