初遇AJAX（初稿）

AJAX这个字眼闪烁于技术领域也不是一天两天的事情了。对其铺天盖地的宣传，大概是在2005年，当时公司里也有同事在尝试这玩意儿，我也有点想瞅瞅这家伙到底是怎么是一回事儿，只是一直太忙就搁下了。今天倒是很偶然的，在一个很无聊的时间里比较表面的了解了一下这个词语。

 

AJAX算起来并非一种技术，而是一堆相互独立又相关的技术的结合体，CSDN的BLOG社区有人作了一个很形象生动且付有寓意的比喻：古时候某位中国人发现了一种现象，把硝酸钾、硫磺、木炭的粉末按比例调配在一起，遇火便能猛烈燃烧－－这便是黑火药。“黑火药”在社会意义上可能算是一个新东西，但是从物理意义上来看依然只是一堆旧有物质的混合体，并非什么新玩意儿。AJAX也确实类似，构成AJAX的关键原有技术（原料）主要有这么一堆：JAVASCRIPT/XML/XSLT/XHTML/CSS，或许你会惊叹，这些都是我们已经熟悉的技术啊，有什么新奇的？啊嗯，确实如此，其新意并不在于技术本身，而在于技术的相互作用和组织形式，如下所示。

• 使用XHTML+CSS来表示信息；
• 使用JavaScript操作DOM（Document Object Model）进行动态显示及交互；
• 使用 XML 和 XSLT 进行数据交换及相关操作；
• 使用 XMLHttpRequest对象与Web服务器进行异步数据交换；
• 使用 JavaScript 将所有的东西绑定在一起。

 至此应该已经明白AJAX的技术体系了，再来看看AJAX倡导者为其下的定义：

 

AJAX全称为“Asynchronous JavaScript and XML”（异步JavaScript和XML），是一种创建交互式网页应用的网页开发技术。

 

那么和传统的WEB开发模式相比，AJAX赖以生存的看家本领是什么呢？也就是说，凭什么让我接受你并使用、推广你？AJAX的诸多倡导者列举了许许多多的这个好处那个好处感觉有点黄婆卖瓜且废话连篇，在我看来最关键的革新与长处有两个，一为“Asynchronous”异步控制，二为局部刷新。前者打破了传统WEB应用的同步模式，使用异步模式可以减少用户等待，可以在画面上实现更多的功能更便利的交互以改善客户感受，在技术层面则可以带来更灵活的应用结构组织方式；后者的优势则比较明显，对于传统的WEB模式而言，用户与Server间的每一次Request/Response，都需要Server端将动态内容重新拼凑整个的HTML并返回给用户－－往往为了让用户看到他正确地为“1+1=?”这个问题选择了“2”这么一个正确答案而重新构造几十KB的HTML内容，但是AJAX使用局部刷新方式，这就意味着，如果用户选择了1+1=2，那么就将评价刷新为“啊！你真聪明！这都答对了！”就可以，其余的整个页面的内容都无需任何变动，根据AJAX倡导者的统计，使用AJAX可以节省95%的网络传输开销，另外WEB应用的运算和IO吞吐的开销同样会因此大幅降低。再说说其它的诸如XML带来的标准化数据交换好处等则是老生常谈这里就不罗嗦了。

 

对于AJAX，我们可以想像，如果将其和业已成熟的WEB SERVICE技术结合起来，将会给WEB应用的技术领域带来什么样的变化？

 

火药是好的东西，但是如果拿它来杀人或者拿它来制作烟花爆竹就不对了－－那样是污染人文环境和自然环境。同样，AJAX再好，也要在它的适用领域里才能发挥应有的优势，如果把它当狗皮药膏到处乱贴，也只会招来一片臭骂，所以，当你打算在某一个产品或项目里面实施AJAX的话，不妨先看看AJAX的重要缺点。

 

首先，AJAX是一个基于JavaScript/DOM/CSS的客户端技术，所谓的客户端其载体便是浏览器，说到浏览器，最让人头痛又历史悠久且无法妥协的问题便是兼容性。目前生产浏览器的厂商很多，而其产品的兼容性问题的焦点便体现在对JavaScript/DOM/CSS的支持上，虽然大多数的内容可以互相兼容，但是，往往就是为了一点点的不兼容而让开发者和用户痛不欲生，古往今来鲜血淋漓的经验教训太多了，AJAX必须考虑这个问题。其次，对于某种人或事或物，其最大的优点往往又同时是其最大的软肋，仿佛这就是辩证法或自然规律？OK，言归正传，看看AJAX的第一大优点是怎样变成弱点的，对于异步处理需要考虑当用户随意提交多个原本在业务上需要按顺序提交的请求的时候，服务端应答的时候就可能得到一个和业务要求不一致的顺序，另外，就算用户是按照顺序提交请求，但是因为每种请求的服务器端运算耗时不一样，同样可能导致应答顺序错位，这是一个需要留给设计者和开发者考虑的问题；再来看看局部刷新，局部刷新最直接的一个弊端就是它将使浏览器原有的的“回退”和“历史记录”功能失去意义，让浏览器厂商大幅修改业已成熟的浏览器标准和技术显然不太现实，所以只能由AJAX框架提供商和开发者来共同干掉这个弊端。然后再提到一个会让已经熟悉传统模式的WEB应用设计者眼睛充血头痛欲裂的缺点，AJAX将可能导致业务逻辑由集中变得分散。高内聚低偶合的观点，一直是软件设计师的指导方针和必然目的，使用AJAX之后，将会有一部分业务逻辑向客户端迁移，也就是说，以前集中在服务端的数据取得和输出页面构成两个工作中的“输出页面构成”将会被转移到客户端中，传统B/S结构的瘦客户端模式也可能会在一夜之间变成一个大胖子，如何重新规划整个应用以适应AJAX的思想，将是设计师要仔细斟酌的一个问题。最后还不得不指出一个连我本人都深恶痛绝的语言问题。AJAX在浏览器端依赖JAVASCRIPT或其同类作为开发语言，众所周知，JAVASCRIPT这种弱语言，不支持强类型、不完全支持OO（这很致命）、执行效率低下、缺乏IDE支持、无法使用重构等等－－罄竹难书也！

 

唉呀呀，这么一大堆怨妇牢骚般的缺点描述是不是把你给吓跑了呢？其实完全不必过虑－－只要我们根据一个原则：适用为好。其实任何技术都一样，在其适用领域便如鱼得水，如果将之用错地方就可能会是一堆难闻的臭狗屎，如果说人家只是要开发一个在红白机上运行的俄罗斯方块，你非要让人家搭上什么WEB SERVICE啊什么J2EE之类的东西，那么就无异于搬起石头砸自己的脚吃力不讨好－－客户会让你喝西北风去的。那么AJAX的适用领域又在哪里呢？其实根据其优点缺点一梳理便知道了，在需要快速响应并避免太多网络带宽消耗、不需要在浏览器端记录历史信息、客户端UI要求灵活多变的场合下，我们将会看到AJAX叱咤风云大显身手，例如目前的Google Map、Gmail等诸多流行应用，已经适用AJAX来武装自己。对我本人而言（要跟我没关系，我还写这文章发这感慨干嘛捏？），早在前几年VB做小玩意的时候我就想，如果在HTML里面能像VB那样随意访问数据库并每次只显示需要的数据该多好啊，当时还拿这问题去问了一趟老师，得到一个答案说：原理上是可以的，只是会比较难。如今看来，AJAX却正好符合我当时的”需求”了。当然自己想的归自己想的，如果无法落实到实际生产中去，也没有意义，但是偏偏我们目前手头上的项目就最适合AJAX的思想，目前这项目就是使用和AJAX类似的方式在处理和显示数据，ASP脚本在服务器端取得数据并作成XML，然后结合指定的XSL一并嵌入到HTML里面返回给客户端，然后浏览器使用JAVASCRIPT和DHTML对象根据XSL对XML作各种预设的处理，诸如排序、高亮、分页、帐票等业务机能。同时，对于页面组织形式，主要分为共通Header/Footer还有工作区域，我们没有使用框架页来组织页面元素，因为框架页无法满足一些业务要求，但是如果使用AJAX就正好合适－－每次的请求应答只需要刷新工作区域和相关的Header/Footer元素就可以了，不用在ASP里面重新构造所有元素，而且更麻烦的是，根据客户要求所有页面元素都需要按照像素和绝对座标进行定位，如果使用AJAX，那么大多数的元素状态，资源颜色座标等信息都不用重新计算，最后根据客户要求，该应用在实际应用的时候本来就是要禁用所有热键以及回退、历史记录等浏览器机能的－－这么一来AJAX的弱点在这个项目里面就真的变成现成的优点了。

 

写在后面：

对于AJAX的诸多弱点，实际上目前已经有很多AJAX的引擎提供商提供了种种相对完善的解决方案，相信不久的将来AJAX便可以克服这些缺点，以在WEB开发领域发挥更大的威力。另外，可喜的，我们看到了越来越多重量级的厂商开始对AJAX提供全面的支持，包括可以算作AJAX之父的MS，还有IBM、SUN等一票子大恐龙，而且，IBM还将在Eclipse的后续版本中提供对AJAX的直接支持，届时AJAX应用的开发将拥有直接的－－而且是优秀的IDE支持。最后，让我们来对比传统的WEB应用学习一下AJAX的结构模型和异步工作模型吧。

 

下图为传统WEB应用和基于AJAX的WEB应用的模型比较


下图为传统WEB应用的同步工作模型


下图为基于AJAX的WEB应用的异步工作模型

 

（注：图片来源为http://www.adaptivepath.com/publications/essays/archives/000385.php）