代码改变世界

我的一些看法:关于AJAX框架的比较

2006-11-27 15:39 Jeffrey Zhao 阅读(...) 评论(...) 编辑 收藏
  Dflying兄最近在对于ASP.NET的AJAX实现进行一基于数据传输大小的比较,图文并茂,颇能够在体现某些方面的问题。这不禁使我我对于这方面也进行了一些思索,这里就说一下我的看法。

在Dflying兄的第一篇文章《ASP.NET AJAX(Atlas)和Anthem.NET——管中窥豹般小小比较》里比较了“AJAX方式更新页面”的功能,结果发现Anthem.NET传输的数据量少于ASP.NET AJAX,那么是否就能说明Anthem.NET真的优于ASP.NET AJAX呢?在第二篇文章《客户端调用服务器端方法——ASP.NET AJAX(Atlas)、Anthem.NET和Ajax.NET Professional实现之小小比较》里比较了“客户端调用服务器端方法”这一功能,结果发现对于ASP.NET AJAX在页面打开时会下载较多脚本,而Anthem.NET在每次调用时会传输较多数据,而AJAX.NET的表现可谓优异。那么我们又该如何来看这个结果呢?

对于第一个例子,我要为ASP.NET AJAX鸣不平,因为使用了UpdatePanel。UpdatePanel的功能非常强大,虽然它的“主要功能”是AJAX方式更新,但是它要“照顾”到的东西就多了,例如管理页面里多个UpdatePanel,各个IScriptControl,要让在更新后页面依旧正确运行等等,而不只是更新数据。但是在第二个例子里我认为又对于Anthem.NET不利了,它包括的控制信息可能会对于别的什么功能有用吧(我猜的,我不会Authem.NET),这个和
上一个比较里的UpdatePanel处于同样的境地,对它不太公平。:)

在第二个例子里,AJAX.NET Pro在表现出众的原因是:“它就是做这件事情的”。AJAX.NET Pro提供的就是“客户端访问服务器端方法”这个功能,而不需要别的。其实在这个功能在实现上ASP.NET AJAX和AJAX.NET Pro的原理是相同的(客户端序列化——服务器端反序列化——执行——服务器端序列化——客户端反序列化),ASP.NET AJAX客户端体积大的原因是因为它提供了很多别的功能:首先不提客户端扩展等“额外”的功能,它对于远程调用也有很多“附加值”,比如WebExecutor,WebRequest,WebRequestManager等等,他们提供了很多事件,也能能够非常灵活地操作一个函数调用(例如在某些情况下Cancel掉),还有各种DefaultCallback,而AJAX.NET Pro就没有提供这些纷繁而强大的功能。

其实事实往往就是这样:现在用于比较的都是非常优秀的框架,这样的框架不太会做一些无用的事情。额外的代码,额外的数据传输应该都是有其目的的,因此单独比一个非常小,几乎不可能单独出现的Scenario往往还不够。我们还需要结合一些别的比较,例如功能的比较,或者在一个庞大,完整的Scenario下,不过这个比较就非常困难了。另外,比较太小的Scenario的结论往往也会有失偏颇,例如ASP.NET AJAX在任何“小功能”的比较时都会传输“大量”的脚本,但是这真的是劣势吗?在性能上请求一次JS时传输相差十几K真的会相差无几,何况除了第一次下载之外之后就会被缓存了。而且,优化PLT(Page Load Time)的一个Best Practice就是“尽量将所有的JS都存放在一个文件内一起下载”,这可以有效地提高性能和避免出现JS错误。因为重新发起一个Request的代价比下载代码的消耗要大不少,而且如果一个文件太小,甚至小于TCP/IP的一个Package,那么更加可谓得不偿失了。

因此如果要根据比较结果来选择合适自己的框架,一定要从多方面考虑:“性能”是一方面(要全面考虑),当然也不能忽视了“易用性”、“功能”和“支持”等各方面。这也是是我推崇ASP.NET AJAX的原因。:)


附:
关于最后我提到的Best Practice:将大量零碎文件放在一起下载,这点对于JS文件还是比较容易做到的,那么图片呢?对于图片来说,其实也是将大量的小图片拼接成一幅大图,然后在IMG的CCS里使用clip。具体方法如下:

首先,将小图片拼接成一幅大的图片,如下:


然后我们需要将其每一个图片单独显示如下,效果如下:

下面就是实现这种效果的代码:
CSS中的clip


这个做法叫作Image Clustering,是优化PLT方法的一种。