Hello World
Spiga

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

2006-11-27 15:39 by 老赵, 7198 visits
  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方法的一种。
Creative Commons License

本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名赵劼(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言

Add your comment

31 条回复

  1. 匿名[未注册用户]
    *.*.*.*
    链接

    匿名[未注册用户] 2006-11-27 17:15:00

    高手呀,希望向天轰穿兄看齐,多出点视频教程,在显示器上看文字信息,太刺看了

  2. 网鱼[匿名][未注册用户]
    *.*.*.*
    链接

    网鱼[匿名][未注册用户] 2006-11-27 17:18:00

    请问下老赵,我用的是ASP.NET AJAX BATE1版本,我现在想要测试一下我写的AJAX页面的效率,我的页面实现的是一个类似LIVE网站的拖动效果,但是我发现在IE下拖动的速度很慢,在FF下拖动速度就很迅速.不知道是什么原因?
    还有我记得在什么地方看过ASP.NET AJAX BATE1版本可以在发布的时候在WEB.CONFIG里面做一个设置,设置以后页面读取的时候只下载页面所用到的JS脚本,提高访问速度.但是我忘记怎么设置了,在GOOGLE上找了一圈也没有找到之类的报道.不知老赵可否指点一下?

  3. 禾口王[匿名][未注册用户]
    *.*.*.*
    链接

    禾口王[匿名][未注册用户] 2006-11-27 18:05:00

    后面的Image Clustering 比较有意思。

    其实,这样对几个asp.net下常用的ajax框架作比较后,刚好可以提供不同应用环境下的不同选择。应该是选合适的,而不是选最好的。

  4. 老赵
    admin
    链接

    老赵 2006-11-27 18:05:00

    @匿名
    讲座对我来说录制起来太麻烦,选题也困难,所以我只能尽力了……:)

  5. 老赵
    admin
    链接

    老赵 2006-11-27 18:08:00

    @网鱼[匿名]
    IE6对于这些其实支持的不好,所以慢是有可能的,我们要做的就是尽量减少运算,降低IE6的压力。IE7就好很多了。
    至于您第二个问题,我不知道这是什么设置……不过这只会影响到您页面的打开速度,不会对您的页面运行效率有很大影响的。:)

  6. 老赵
    admin
    链接

    老赵 2006-11-27 18:10:00

    @禾口王[匿名]
    是啊,关键是“合适”。
    不过只用某一种“AJAX特性”的应用的确比较少,而且说实话ASP.NET AJAX的与别家的“劣势”其实也不明显。
    所以我对于选择ASP.NET下的AJAX框架的意见是“用ASP.NET AJAX总没错,用别的要斟酌”。:)

  7. lovecherry
    *.*.*.*
    链接

    lovecherry 2006-11-27 18:11:00

    为了一点点的效率在CCS里使用clip不值得,开发成本都赚不回来

  8. 老赵
    admin
    链接

    老赵 2006-11-27 18:15:00

    @lovecherry
    这个方法可能的确有点极端,不过不失为可以在后期进行优化的方式,而且在有时候的确比较重要。
    而且其实我们可以通过写一个方法来用document.write写出所需的HTML,开发成本就下来了。:)

  9. Cat Chen
    *.*.*.*
    链接

    Cat Chen 2006-11-27 18:36:00

    如果Image Clustering能够在build的时候自动完成,那还是不错的。

  10. 老赵
    admin
    链接

    老赵 2006-11-27 18:54:00

    @Cat Chen
    估计比较困难,尤其是一些“不传统”的图片显示。呵呵……

  11. Tseng
    *.*.*.*
    链接

    Tseng 2006-11-27 20:45:00

    第一次知道可以将一张图片分开来显示,以前我都是用PS将一张图片分割成好多小图片.

  12. 蛙蛙池塘
    *.*.*.*
    链接

    蛙蛙池塘 2006-11-27 21:13:00

    呱呱,我想只用yahoo ui,里面有个connection组件,用来做xml http访问,我想再指定一套xml协议,客户端给服务端发什么命令,服务端作出相应多输出,然后客户端再解析,这样服务端如果是asp.net,可以很方便的移植到php,structs等,要不用你的aspnet ajax,以后.net撑不住了,可以往linux+php+mysql平台。

    这样性能最好,依赖性也好,可移植性强,你说呢?有啥弊端?

    举个例子
    客户端发送http请求
    <iq type='set' id='get_product'>
    <categoryid>3</categoryid>
    </iq>

    然后服务端就返回
    <iq type='set' id='get_product'>
    <product name="pro1">
    <price/>
    <description/>
    </product>
    <...>
    </iq>

    反正别管是php,还是jsp都能相应xml,也能返回xml对吧,这就行了,客户端管客户端的,服务端管服务端的,职责分离嘛,也容易移植,性能也好,结构也清晰,往后不用ajax了,用socket发送xml命令,让socket主机回应xml也行呀。对吧。

  13. 老赵
    admin
    链接

    老赵 2006-11-27 21:59:00

    @Tseng
    其实即使用传统的DIV,把它的overflow设为hidden,再设里面图片的位置也能得到相同的效果。:)

  14. 老赵
    admin
    链接

    老赵 2006-11-27 22:01:00

    @蛙蛙池塘
    是啊,这个相当于一个不依赖于服务器端的客户端框架了。弊端就是:开发成本高。:)
    这个就是客户端框架和服务器端框架的区别啊,选择您觉得最适合的才是最好的。

  15. 大剑师
    *.*.*.*
    链接

    大剑师 2006-11-27 23:41:00

    @Jeffrey Zhao
    兄弟你的给出的Style有问题吧

  16. 老赵
    admin
    链接

    老赵 2006-11-27 23:47:00

    @大剑师
    的确错了,谢谢提醒阿,已经改好了。:)

  17. 数据绑定者
    *.*.*.*
    链接

    数据绑定者 2006-11-28 09:26:00

    支持老赵,我看ajax beta2的Sample网站,在CollapsiblePanel控件展开后,下面的层都可以自己自动加高,我自己搞了个网页,想实现这个效果,老是被层盖住了,郁闷……

  18. 老赵
    admin
    链接

    老赵 2006-11-28 09:44:00

    @数据绑定者
    能不能让我看一下代码呢?:)

  19. 数据绑定者
    *.*.*.*
    链接

    数据绑定者 2006-11-28 09:44:00

    以前一直觉得web的开发功能还是不如WinForm的易用,有了Ajax,我改变了自己的看法

  20. 数据绑定者
    *.*.*.*
    链接

    数据绑定者 2006-11-28 09:45:00

    @Jeffrey Zhao
    代码 ?我觉得是CSS的原因吧?你要看CSS么?

  21. 老赵
    admin
    链接

    老赵 2006-11-28 09:59:00

    @数据绑定者
    表现能力的话的确已经很不错了。不过开发难度上还是有一定差距。:)

  22. 老赵
    admin
    链接

    老赵 2006-11-28 10:00:00

    @数据绑定者
    尽量完整些吧,包括相关页面代码。:)

  23. 数据绑定者
    *.*.*.*
    链接

    数据绑定者 2006-11-28 13:47:00

    比较多,挺乱的,我就想实现一个层如果变大了,撑开别的层,而不是层叠。

    就像用Table的一样,用层总是被覆盖,能给个例子么?呵呵

  24. 蛙蛙池塘
    *.*.*.*
    链接

    蛙蛙池塘 2006-11-28 17:46:00

    网络上一直在强调Ajax如何使得WEB用户如何改善体验,如何与众不同,须知任何一门新技术都是尤其缺点,我们必须要小心应用,Java天生速度慢,所以C++依然非常流行,EJB相当复杂,然后Hibernate才能大行其道。Ajax也不例外,在此简要列出几个,以供WEB 程序员,尤其准备在WEB中引入Ajax技术框架得人们注意:

    1 .、Ajax使得MVC中C这一方的工作量大大加大,需要编写大量,控制也比较复杂的JavaScript代码,同时由于DOM在不同浏览器上支持的程度不同,这也带来了一定的复杂性。

    2、多线程带来的问题,举个例子,一个用户打算转账,已经输入了金额,并且点击确定(这个过程使用Ajax实现),然而可能由于后台的处理问题,导致用户迟迟得不到反馈,然后又点击退出该页面,这样的结果是什么估计我们也不知道。

    3、性能上的影响,都说 Ajax给用户带来的速度变快了,事实上并不一定如此,假设一个页面上使用到了多个Ajax这样一个页面就同时触发了多个线程,这样子后台的压力更大了,如果用户量少也许看不出什么,一但是规模用户,必然对服务器造成巨大压力!

    简要介绍这几个,如果大家还有什么补充,多多留言阿!也希望大家踊跃提出解决方法 :)


    想请教一下,上面说的这些,大家有反对意见吗?

  25. 老赵
    admin
    链接

    老赵 2006-11-28 17:53:00

    @数据绑定者
    正常情况下的确应该撑开的,您的position是多少呢?

  26. 老赵
    admin
    链接

    老赵 2006-11-28 17:55:00

    @蛙蛙池塘
    您说的几条都很正确。这些都是AJAX的经典问题,AJAX被滥用的确会带来一些问题。:)

  27. 小蜗牛
    *.*.*.*
    链接

    小蜗牛 2006-11-28 20:54:00

    对的,看了以后学到不少东西。

  28. lovan[未注册用户]
    *.*.*.*
    链接

    lovan[未注册用户] 2006-12-07 21:28:00



    (主页改版中,现在就不拿出来了)
    可惜了,最近几天一直忙着项目,没赶上大讨论的时期。我一直也关心着Ajax的一些效率问题,尤其是针对ASP.NET2.0的

    Framework。对于您的观点首先是表示赞同,但是我个人觉得片面了。首先我不太想比较ASP.NET Ajax和Anthem.NET这两个框架,因为我觉得比较这两个框架没多大意义,如果我们把底层的东西弄明白了,再比较这两个框架,好坏也就很明显了。

    对于您的观点:在性能上请求一次JS时传输相差十几K真的会相差无几,何况除了第一次下载之外之后就会被缓存了。而且,优化PLT(Page Load Time)的一个Best Practice就是“尽量将所有的JS都存放在一个文件内一起下载’,这可以有效地提高性能和避免出现JS错误”,我比较赞同,但是也不排除网络差的地方,几K的东西也会有很明显的滞留。但是不能光从JS文件这一个层面来讨论,因为我们往往开发的是一个网站,可能还比较大,那么下载的就不是简单的JS文件了,而是一大堆的文字、图片……这样来说,我们就得好好考虑效率的问题,十几K的差异是绝对不能忽略的,而如果我没有记错的话,压缩之后的MicrosoftAjax也有60多K(注意:我们还没有考虑加入什么WaterTextBox,RoundedCorner,Validators……这类的控件,随便加一个,就要增加好几K),一个中等大小的网页大概也有80K左右吧(注意:这里只考虑纯HTML,不包括js,images,css。如果是用ASP.NET做的,估计这个数字还要加上15K),好吧,就这些东西,也快150K了,就这样一些东西下载就已经够呛的了,如果还有一些图片,这样的速度也是惊人的慢了。我开发过这样的网站,最开始没有考虑效率问题,结果导致一塌糊涂,效率低的可怕。

    同时我想从另一个角度来说这个问题,这两个框架都是针对ASP.NET2.0的,ASP.NET2.0的面向对象化实际上是以减低一部分效率为代价的。我们在开发的时候(尤其是新手)往往没有注意优化的问题,尤其是使用到DataList、GridView、Reapter这样一些控件的时候,会产生几十K,甚至上百K的ViewState,这些东西通过XMLHttp传输的速度底的可怕,还完全不知道为什么。另外就是我们大量使用WebUserControl,这是能提高开发效率,不错,但是问题又来了,一个在Category的用户控件中的Button1生成的名称是Category$Button1,如果有更深次的,那么就更大,如果有很多重复的Label之类的控件生成的代码就“无缘无故”地大了好多,这样一来,效率就成了一个很关键的问题,而不是仅仅考虑下载一个10几K的JS文件了。同时我想说像MiscrosoftAjax这样的框架太过于臃肿了,Javascript语言本身的特征,以及被设计出来的初衷都被篡改掉了,居然Microsoft还将它“C#化”了,我只能表示悲哀,对于那部分依旧在吹捧MiscrosoftAjax的人,希望能从本质上好好考虑清楚再做结论,不要一味说好,Ajax是用来减少网络流量、提高用户体验的一种工具,而不是要适得其反。

    在遵从用户体验至上的今天,效率依旧是最为重要的问题,我们的网络也还没有达到300K的下载速度和5K没有区别的境地,同时Web现在做的越来越大,效率这个问题更是需要认真考虑。
    好了,先说这么多吧,个人现在正在开发类似MagicAjax这样的小型框架,不过我还是嫌大了,专门针对无刷新开发一个高效率的UpdatePanel,我认为这才是Ajax的长处,好,闪先。

  29. 老赵
    admin
    链接

    老赵 2006-12-07 21:49:00

    @lovan
    您的看法有一定道理,但是我并没有觉得ASP.NET AJAX臃肿地让人难以接受。它的确比较大,加上了一些ControlToolkit的JS,会变得更大,似乎的确很可怕。不过这就是缓存所起作用的时刻了。第一次请求会下载数百K的文件,而以后再打开得到的则都是304了。因此现在许多大型JavaScript应用都会在一开始先使用一张“加载页”来下载各种资源。您可以计算一下下载的字节数,您会发现缓存的神奇作用。使用ASP.NET AJAX的确大大减少网络流量了,这应该是AJAX的“初衷”吧。
    至于JavaScript的“初衷”,为什么说ASP.NET AJAX违反了呢?初衷本来又应该是什么呢?其实“JavaScript只能作为轻量级的点缀”这种看法已经停留在数年前了,但是JS“特效”满天飞,现在JS已经真正成为一种用于开发大型应用的工具了,ASP.NET AJAX只是使用JS编写“大型”框架的其中之一。
    还有您说的ViewState通过XMLHttp传输的问题,这是UpdatePanel才会遇到的状况,这是因为需要保证页面的正确性,而禁用ViewState就没有问题了。另外,就是因为UpdatePanel有这个问题,因此其实就微软官方来说,它也是更推荐客户端的Web Service访问,而不是UpdatePanel。Web Service的数据传输量非常的小,小得令人赞叹。

  30. linuxping[未注册用户]
    *.*.*.*
    链接

    linuxping[未注册用户] 2007-02-24 04:48:00

    盖住了???

    Z-index改大点!

  31. 老赵
    admin
    链接

    老赵 2007-02-24 07:38:00

    @linuxping
    什么东西被盖住了?

发表回复

登录 / 登录并记住我 ,登陆后便可删除或修改已发表的评论 (请注意保留评论内容)

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

评论内容(大于5个字符):

  1. Your Name yyyy-MM-dd HH:mm:ss

使用Live Messenger联系我