AJAX基础之ajax的优缺点

传统模式相对于Ajax模式在性能上的最大区别就在于传输过数据的方式，在传统模式中，数据提交是通过表单（form），获取数据是整页的HTML+CSS，而Ajax模式只是通过XMLHttpRequest向服务端提交希望提交的数据，并通过XML返回需要的少量数据或者HTML Text片段，这样相对于传统模式来说无疑节约了很多资源。下面我们从三方面分析Ajax对资源的节约。

首先我们谈谈服务端处理数据，在传统交互模式中，服务端对客户端的数据处理都是以页面为单位的，客户端提交页面表单以后，服务器分析提交数据后会将整个页面重新生成为HTML+CSS发回给客户端呈现。很多时候程序其实只是希望提交很小一部分数据，并改变一小部分的数据显示，如投票时为赞成加上一票并将原来的“4票”显示为“5票”，这时却不得不将整个表单提交，并在服务器端处理整个页面并回传，这极大地浪费了宝贵的服务器资源。

借助于Ajax技术，我们有了一种新的选择，我们只回传用户对赞成投了一票这个信息，可能这个信息只包含几个字节，返回时我们也只返回投票成功这个信息，返回结果也只包含一个状态位，通过Ajax engine改变页面并显示数据，在服务端只是执行了一个简单的业务逻辑，并没有处理页面显示回传的问题，这样对于服务端来说减少了很多数据处理压力。

我们再来看看网络带宽的情况，前面其实已经提到，使用Ajax的方式处理和传输的数据量都相对于传统方式小很多。我们可以简单算一算，通常我们一个页面的HTML Text大小在30KB到100KB的样子，如果控件多一些，页面的大小会大得让你吃惊，特别在ASP.NET中一个页面控件多一点，并且控件都打开了ViewState，页面文本的大小是延迟Web相应得罪魁祸首，曾经笔者帮助朋友调整一个业务页面，这个页面是一个GridView，单元格里都是DropDownList，需要用户频繁地选择项并回传数据，开发人员觉得回传和刷新页面都非常困难，响应变得十分缓慢。经过笔者的分析发现回传的HTML Text大小高达1MB多，这是服务器响应缓慢的主要原因，用户实际上只是想回传一个控件的数据，但是不得不把所有控件的数据回传并又一次加载基本上相同的数据。这样的用户体验当然是无法让人忍受的。经过笔者引入Ajax技术并调整以后，整个页面执行效率变得很高，页面在最终转跳之前的数据获取都没有刷新页面，使之得到了较好的用户体验。以前通常需要刷新几十次页面，与服务器之间上传下载近百兆数据才能完成的业务，变成在仅仅交互几百KB就完成了业务，这样对带宽的节约得到的显著的性能提高在很多地方都得以一见。

最后我们再看看客户端的情况，通常我们觉得在客户浏览器端多维护了一个Ajax engine会比传统方式消耗更多的客户端资源，但是我们细想一下，在传统方式中回传加载页面时呈现页面需要消耗处理机资源，在刷新完成后保存前进后退的锚点数据同样需要消耗客户端的内存资源，相对于这些资源来说一个小小的Ajax engine对象所耗费的资源是可以忽略不计的。相反地使用Ajax技术后避免了页面的频繁刷新，反而能较好地避免浏览器因加载分析HTML引起的假死而长期占用处理机资源的情况。

从这三点可以看出，Ajax相对于传统的交互方式在各方面都有着很大的优势，因此Ajax在现今有着越来越广泛的应用，我们在越来越多的地方能看见Ajax的身影，Ajax也带给我们越来越优秀的用户体验。

但是，为什么Ajax相对于传统模式有着那么多优越性却没有完全取代传统模式，成为最优开发模式呢？这不得不让我们提起Ajax的不足，以及它与生俱来的缺陷，世界上并没有完美的事物，同样Ajax也并不是一项完美的技术。

 

事物都会有它的两面性，既然Ajax有着那么多优势，相应地它也会有很多不足之处。其实Ajax的不足大多数来自于外部，相信随着Ajax技术的发展，这些不足在有一天会消失。

首先，Ajax碰到最大的问题就来自于浏览器。对于XMLHttpRequest对象的支持，Internet Explorer是在5.0版本才支持的，Mozilla﹑Netscape等浏览器支持XMLHttpRequest则更在其后，如果说使用较老版本的浏览器访问Ajax页面是不可能得到正确结果的。如果说要使得老版的浏览器能够正确访问，我们不得不多写一个传统方式版本，并嗅探浏览器版本来显示相应的内容，无疑这样大大增加了开发难度及成本。另外一个问题就是在Internet历史长河中一直存在并一直没能解决的问题——浏览器之争。对于各个浏览器阵营来说，各行其道已经不是一年两年了，程序员在客户端脚本开发中顾此失彼也是常有的事，为了兼顾Ajax应用能在各个浏览器中都能正常运行，程序员必须花费大量的精力来比较各个浏览器之间的差别来使得Ajax应用能够很好地兼容各个浏览器。这本来是浏览器兼容客户端脚本的问题，但谁让JavaScript是Ajax的重要组成部分呢。这使得Ajax开发的难度高出普通Web开发很多，也是许多程序员对Ajax望而生畏的原因之一。

其次，Ajax改变了我们通常的Web浏览习惯。最显著的一个改变就是在Ajax中前进和后退按钮的失效，虽然可以通过一定的方法来添加锚点使得可以使用前进和后退（Gmail在这一点上似乎做得不错），但相对于传统的方式却麻烦了很多，对于大多数的程序员来说宁可放弃前进后退的功能，也不愿意在繁琐的逻辑中去处理这个问题。对于用户来说经常会碰到这种情况，当点击一个按钮触发一个Ajax交互后又觉得不想这样做，接着就去习惯性地点击后退按钮，结果发生了最不愿意看到的结果，浏览器后退到了先前的一个页面，通过Ajax交互得到的内容完全消失了。其次用户经常在点击一个按钮后对页面没有刷新而感到奇怪，在多次点击后才观察到页面微小的变化或出现的提示。如果用户想在Ajax应用的页面上通过拷贝链接来与朋友分享资源，相信你朋友看到的内容和你看到的并不是一回事。用户对于Ajax技术的不适应相信随着Ajax应用的增多会慢慢改善。

再次，对于互联网上搜索引擎的支持也是Ajax的一块心病。通常搜索引擎都是通过爬虫程序来对互联网上的数以亿计的海量数据来进行搜索整理的，可惜与Flash应用在搜索爬虫上遇到的问题类似，爬虫程序现在还不能理解人们那奇怪的JS代码和因此引起的页面内容的变化，这使得应用Ajax的站点在网络推广上相对于传统站点明显处于劣势。但是相信随着Ajax技术的大面积应用，Web 2.0标准的推广，以及新的搜索引擎技术的发展，Ajax一定能够在今后发展得更好。

最后，我们就要谈谈关于开发的问题。因为Ajax是一个综合的技术，是集多种技术为一体的边缘技术，这无疑为对其基础库支持相对于其他Web技术滞后很多，长期以来Ajax的开发人员从事着刀耕火种的工作，或者不得不自己开发大量的基础类来应对自己大量的开发工作，毕竟Ajax在开发上的灵活很难让像ASP.NET那样提供一个很好的基础库来支持开发工作。随着Ajax的发展现今国外很多公司都相继推出自己的针对ASP.NET的Ajax控件或者基础库产品。国外比较完善的Ajax成套控件有Telerik r.a.d Ajax，这套控件提供了大量的Ajax控件以及丰富的Ajax应用，在稳定性和应用效果上都是一流的，但可惜是非开源的收费软件，并且效能不敢恭维。同样微软也不为人后地推出了针对ASP.NET的Ajax框架代号为Atlas（后更名为ASP.NET Ajax Extensions），目的是简化Ajax在ASP.NET中的应用，但是由于Atlas在实现方式上较为累赘，并且自身Bata版本频出漏洞，使得人们对它不感不冒，现在大规模应用它的项目少之又少。对于ASP.NET的Web应用人们找到了一个更好的选择Ajax.NET。

在下一篇文章中我们将介绍到什么是ajax.net.