我的一些看法：关于AJAX框架的比较
2006-11-27 15:39 Jeffrey Zhao 阅读(7224) 评论(31) 编辑 收藏 举报
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方法的一种。
在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方法的一种。
