ajax|web|程序一、引言
一个理想的用户接口对用户最好是不可见的-仅在用户需要时提供选择，否则并不干涉他们的工作而让其专注于手头的工作。然而，这并不是一件容易的事情。如今，我们变得习惯于通过并不十分令人满意的UI进行日常工作，直到有人向我们展示一种更好的方法。
由于用于显示文档内容的基本web浏览器技术又被推进一步进而超出以前它们所能及的范围，所以，如今的互联网正在经历着这样的实现。
Ajax(异步JavaScript+XML)是一个非常新的名字，为Adaptive Path的Jesse James Garrett所创建。其中，Ajax的某些部分以前被描述为动态HTML和远程脚本。
Ajax的出现不仅仅是一个新名字的问题。从技术和商业的角度看，围绕Ajax还有大量激动人心的东西。从技术上讲，Ajax实现了web浏览器技术中大量的尚未实现的潜力。从商业上看，Google和其它一些主要商家正在逐步使用Ajax技术，从而让公众认识到一个web应用程序所能做的事情。
以前我们习惯的典型web应用程序如今正在承受着巨大的压力，因为逐渐复杂的基于万维网的服务正日趋成熟并开始应用于互联网。各种新技术争相涌现出来以克服这些问题，而Ajax仅使用现有的互联网技术就能够更好地表达这些思想。
利用Ajax，我们重用了一堆原有技术但却扩展了它们原来所能及的范围。我们需要能够管理这种我们引入的复杂性。本文将讨论怎样实现这些技术，而且还要讨论一下管理大型Ajax工程的问题。我们将介绍Ajax设计模式及其怎样帮助我们完成工作。设计模式帮助我们捕获我们的知识和经验，用我们现在的技术并且使之与其它对象进行通讯。通过把规则引入到代码基之上，它们就能够方便创建应用程序-可以据变化对工程加以修改和扩展。使用设计模式进行开发甚至是一种喜悦！
为什么说Ajax是丰富的客户端？
构建一个丰富的客户端接口比设计一个WEB页面要复杂。那么是东西导致我们这样做的？好处有哪些？什么是丰富的客户端?
一个丰富的客户端有两个关键特点：它是丰富的，而且它是一个客户端。
让我稍作解释。丰富指的是客户端方式。一个丰富的客户端模型-是指它能够支持各种输入方法且能够直观又非常及时地作出响应。尽管我们称其为"丰富的"，但是它必须与象字处理器和工作表等现代桌面应用程序一样好才真正丰富。下面让我们看一下为达此目的所具体要求的实现技术。
二、比较用户体验
在这里，让我们讨论一个工作表程序的实例。当我在工作表输入一些简单的公式时，我可以有几种方式与之交互-现场编辑数据，用键盘和鼠标导航数据和通过鼠标拖动重新组织数据。
当我在操作这些时，软件给我反馈-鼠标光标形状改变，当我在按钮上移动时按钮高亮，选定的文本改变颜色，高亮的窗口和对话框以不同形式显示，等等（图1）。
图1 这个桌面工作表应用程序说明了多种用户交互的可能性。 |
这些是当今用户丰富的交互的主要表现。这样的工作表应用程序就是一个丰富的客户端吗？还不是。
在一个工作表或类似的桌面应用程序中，逻辑和数据模型都在一个封闭的环境中运行-在此它们彼此都能清晰可见，但是却把外界拒之门外（图2）。我的客户端定义是一个程序-它能够与一个不同的独立的进程通讯-典型地它运行于一个服务器上。传统地，该服务器比客户端更大更强壮并且存储了海量信息。客户端允许终端用户观看和修改这些信息，并且如果有一些客户连接到同一个服务器上，它允许他们分享该数据。图3显示出一客户机/服务器架构的简单图解。
 图2 一个独立桌面应用程序的图解架构。 |
该应用程序运行于其自身的进程之中-在其内数据模型和程序逻辑彼此清晰可见。在同一台计算机上运行的该应用程序的第二个实例除了经由文件系统之外无法存取第一个实例的数据模型。典型地，全部程序状态存储在单个的文件中-当该应用程序运行时它被锁定以阻止任何信息的同步交换。
 图3 客户端/服务器系统和n层架构图解。 |
该服务器提供一个客户可以用之进行交互的可共享的数据模型。客户端仍然维持它们自己的部分数据模型以达到快速存取。多个客户可以与同一个服务器进行交互，而此时在单个对象或数据库行良好粒度级上控制的资源被锁定。该服务器可以是一个单个的进程，就象在90年代以前的早期的传统型客户端/服务器模型或由若干中间件层、外部web服务等组成的现代模型。在任何情况下，从客户的角度来看，服务器具有单个入口点并且可以被认为是一个黑盒子。
当然，在一现代的N层架构中，服务器将能与例如数据库这样的后端服务器通讯-这导致了中间件层的出现-它们既充当客户端又充当服务器端。典型地，我们的Ajax应用程序位于这个链的一端上-只担当客户端，所以我们可能把整个N层系统看作单个黑盒子-我们把它标记为服务器，以便于我们当前的讨论。
我的工作表只专注于它自己的存储在本地内存和本地文件系统上的数据。如果它架构良好，数据层和描述层之间的耦合可能相当松散，但是我无法把它通过网络分解与共享。所以，从我们的描述层目标来看，它不是一个客户端。
当然，Web浏览器是客户端，它连接web服务器并从中进行页面请求。这些浏览器具有一些丰富的功能来管理用户的web浏览，例如后退按钮、历史列表和多页面存储多个文档。但是如果我们把一个特定站点的web页面看作一个应用程序，那么这些通用浏览器控制便不能再关联到应用程序，就象Windows开始菜单或window列表相关于我的工作表一样。
让我们看一个现代web应用程序。主要因为每个人可能都听说过它，所以我们将选择Amazon-在线书商为例(图4)。现在，我把自己的浏览器指向Amazon站点；因为该站点从我的上次访问能够记得我是谁，所以它先给我显示一个友好的问候、推荐书列表和关于我已购买书的历史信息。
 图4 Amazon.com首页。该系统记得我以前访问过该站点，其中可导航的链接是通用信息和私人信息的混合。 |
从建议列表中点击一个标题将把我导向一个独立的页面(也即，该屏幕闪烁一下，于是我就失去了几分钟前可以看到的列表)。于是新页面中又会充满各种上下文信息（见图5）。
 图5 Amazon.com站点书籍详细资料页面。 |
再一次，大量的结合有通用和私人信息的超链接出现。尽管如此，大量的细节与图4所示极为相同-这，由于web浏览器的基于文档的操作，必须被重新转送到每个页面。
简言之，我向你展示了非常丰富的紧密联系的信息。而且我与这种信息交互的唯一方式是通过点按超链接并且填写文本表单。如果我在浏览站点时的键盘输入过程中睡着了并且第二天才醒来，那么在我刷新全部页面之前我不会知道新的哈里·波特书已经发行。我不可能带着我的列表从一个页面转到另一个页面，并且我不可能缩放该文档的一部分来一次观看多处的内容。
这并不是在诋毁Amazon，在非常有限的限定内它工作得相当优秀。但是与工作表相比，它所依赖的交互模型毫无疑问相当有限。
那么，为什么在现代web应用程序中存在这么多的限制呢？目前，存在很多技术上的原因。因此，现在让我们作进一步分析。
[1]
