[IT168技术文档]
原文地址：http://www.codeproject.com/Ajax/aspnetajaxtips.asp
源码下载：http://www.codeproject.com/Ajax/aspnetajaxtips/ASPNETAjaxTips.zip
原文发布日期：2006.12.22
介绍
微软最近发布了ASP.NET AJAX的Beta 2版。虽然它是一个非常强大的框架，但是当你在web 2.0的世界中要开发一个真正的AJAX web站点的话，就会遇到很多问题，而且你几乎找不到任何相关文档。本文中，我将介绍一些在开发Pageflakes中所学习到的高级经验。我们将会看到ASP.NET AJAX一些功能的优缺点，如批调用（Batch Call），调用超时，浏览器调用拥堵问题，ASP.NET 2.0中web service响应缓存的bug等等。
本文最后更新：
为什么要使用ASP.NET
一些人在看到Pageflakes的时候，首先产生的问题就是“为什么不使用Protopage或者Dojo库？而是Atlas？”微软的Atlas（已重命名为ASP.NET AJAX）是一个非常有前途的AJAX框架。微软为了这个框架做了很多努力，制作了大量可重用的组件，这样可以减少项目的开发时间，这样的话只要很少的工作量即可让用户的web应用程序有一个完美的界面。它与ASP.NET融为一体，并且兼容ASP.NET的Membership和Profile。AJAX Control Toolkit项目包括了28个扩展（译注：现在有34个），可以简单的把它们拖拽到页面上，然后通过一些属性设置就可以产生非常酷的效果。看看那些例子你就会知道ASP.NET AJAX带来了多么强大的功能。
在我们最初开发Pageflakes的时候，Atlas还处于幼儿阶段。我们只能使用page method和Web Service方法来调用Atlas的特性。开发者们不得不开发自己的拖拽、组件构造、弹出、伸缩/展开等特性。但是现在，Atlas提供了所有这些功能，所以可以大大节省我们的开发时间。最令人惊奇的是Atlas提供了web service代理的特性。你可以指定<script>标签到一个.asmx文件，并得到一个JavaScript类，它会根据web service的定义被正确的生成。这使得添加或移除一个web service变得非常简单，而且在web service中添加或移除方法都不需要客户端作任何改变。Atlas也提供了很多基于AJAX调用的控件，并且提供了在JavaScript中捕获丰富异常信息的特性。服务器端的异常可以被精确的抛给客户端的JavaScript代码，你可以捕获它们并格式化这些错误信息，然后显示给用户。Atlas与ASP.NET 2.0结合起来工作得非常出色，完全消除了整合问题。完全不需要担心page method和web service的验证和授权问题，所以可以大大减少客户端代码的开发量（当然，也正是因为如此，Atlas运行时也变得非常巨大），相对于其它的AJAX框架来说，将有机会把更多的精力放到自己的代码开发上来。
Atlas最近的版本可以与ASP.NET的Membership、Profile完美的结合，提供了在JavaScript中登录和注销的特性，而不用发postback给服务器，将可直接从JavaScript中读取和写入Profile。当需要在web应用程序中使用Membership和Profile的时候，这将变得非常容易，例如我们做的Pageflakes
在Atlas的早些版本中，没有使用HTTP GET调用的方法。所有的调用都是HTTP POST，所以调用的代价是非常大的。而现在可以方便调用是HTTP GET，一旦使用HTTP GET就可以利用HTTP响应缓存特性，我将很快介绍这一特性。
批调用并不一定快
ASP.NET AJAX的CTP版本（之前的版本）里有一个特性，就是允许在一个请求里包含多个请求。它工作时你不会注意到任何事情，而且也不需要写任何特殊的代码。一旦使用了批调用特性，那么在一次批调用期间，其中所有的web service调用都会被执行，所以它将减少回发时间和总响应时间。
实际的响应时间可能减少了，但是感觉延迟却变长了。如果有3个web service被批量调用，那么第一个调用不会最先完成，而是所有3个调用会在相同的时间完成。如果每一个web service调用完成后都更新UI的话，将不会一步一步更新，而是在所有调用一起完成后再一起更新UI。结果不会看到UI被快速更新，而是在UI被更新之前有一个长时间的延迟。如果说调用中的任何一个(比如第3个调用)下载了大量数据，那么在所有的3个调用完成之前用户不会看到任何变化。所以第一个调用的执行时间几乎接近3个调用的总执行时间。虽然减少了实际的总计处理时间，但是会感觉有更长的延迟。当每个调用都只传输少量数据的时候批调用是非常好的，这样，3个小型调用就会在一次回发中执行完。
让我们看看3个调用是如何一个一个被完成的，这将说明这些调用实际上是如何被执行的。
第二个调用到达服务端的时间要比第一个调用长，因为第一个调用吃光了带宽。同样的原因，下载也就会花更多的时间。浏览器同时打开了两个连接到服务器端的连接，所以在同一时间，只能处理两个调用。一旦第一个调用或第二个调用完成后，第三个调用才能被处理。
当3个web service在一次请求中被批调用的时候：
这里总计下载时间将会有所减少（如果IIS的压缩功能启用的话），并且只需一次网络响应。所有的3个调用一次被发往到服务端后全部执行，组合而成的三个调用的响应是在一次调用中下载。但是对于用户来讲，他们会感觉速度变慢了，因为UI的更新发生在所有批调用完成之后。这个批调用完成的总时间总是要长于两个调用的。并且，如果有大量的一个又一个的UI更新，IE将会冻结一段时间，这将给用户带来一个糟糕的体验。一些时候，时间较长的UI更新会导致浏览器出现“白屏”，但是FireFox和Opera不会有此问题。
批调用也是有一些优点的。如果你的IIS启用了gzip压缩功能的话，将对全部结果进行压缩而不是分别压缩每个结果，那么总下载时长就会少于单独调用的下载时长。所以，通常批调用都是一些小型调用的话会比较好。但是如果调用会发送或者返回较大数据的话，比如20KB，那么最好就别使用批调用了。批调用还有另一个问题，比如说前两个调用非常小，第3个调用十分大，如果这3个调用被批调用的话，那么前两个小的调用就要延迟很长时间，因为第3个很大。
