终于完成了最后一次的更新，修正了所有的Bug，当然还有可能有潜在的Bug，不过真是让 人觉得很烦恼的。好好的一个网站让人搞了好多遍，测试了n次之后才能完全运行正常了。今天这个问题倒不是潜在的Bug，而是涉及到关于MagicAjax和Atlas的效率的问题。最开始的 UpdatePanel我选择的是Atlas的，结果产生了让人难以置信的后果：CPU消耗太大，导致所有 的Session全部丢失。这个是我所未料到的，于是出于性能方面考虑，我开始调试MagicAjax和Atlas在CPU方面的损耗情况，以及在不同浏览器中的表现行为。结果出乎我所料，MagicAjax 表现出来的性能似乎要好的多。如下几条是我选择MagicAjax的理由。

1. MagicAjax的CPU消耗较少。这个最难能可贵了，由于耗服务器上的CPU导致所有Session丢 失的，这样就会导致数据重新读取，而重新读取又会增加CPU负担，这样就会导致恶性循环。 尤其是大量使用存储过程的时候，服务器的压力是很大的。
2. MagicAjax对GridView和Datalist的自定义分页的访问速度要快的多。采用异步读取更新 显示数据的时候，MagicAjax的数据更新速度要快于Atlas。这个可能是由于MagicAjax设计的 初衷就是从这样一些数据绑定控件入手的。
3. MagicAjax支持后退和前进！这个是我始料未及的，因为最开始我一直都是在IE上测试的 ，没有看出有这样一个功能。但是在Firefox里面测试的时候，我居然神奇的发现MagciAjax是 支持后退和前进的。
4. MagicAjax能更好的和ASP.NET2.0组件结合使用。并且方式更为简单，更为直接。

好，说完它的好处之后，现在再来谈谈Atlas的UpdatePanel的几大弊端，这也是我选择 MagicAjax的几大理由。

1. 在不同浏览器中的支持不一样<！这个有点让人摸不着头脑了，经过我的调试，Atlas在 Firefox中支持的最好，无刷新的感觉也要好，并且几乎没有发现Bug。但是在IE中，Atlas的 无刷新的感觉给人的要差，同时有着让人生厌的Bugs。比如要自己定义CommenPage类，要 DisableUpdatePanelForSafari=true；在网页中有RoundedConnerExtenderAtlas组件的时候， 会产生莫名奇妙的横线。
2. Atlas的UpdatePanel的EventTrigger在设置监听的事件会有导致IsPostBack上的一些问题 ，而这些问题不得不重新考虑代码的设计，尤其是面对一些复杂项目的时候。而MagicAjax就 没有这样的问题，因为它只更新在AjaxPanel中的元素，而AjaxPanel以外的元素是没有发生任 何PostBack之类的变化的，因而效率较高。
3. Atlas在使用的时候最好没有要下载的别的.js文件。最我在这个Blog上放置了一个Google的广告，要下载一个.js文件，然后问题就出来了，Atlas组件居然拒绝工作了！我废了好大的劲才找到症结之所在。
4. Atlas耗CPU，效率不高，无后退，这些是最大的毛病，在谈及MagicAjax的时候已经多次 强调过了，这里也就不用再拿出来谈及了。

当然MagicAjax也不是没有毛病的，至少目前为止我就发现了它的两个Bugs。第一个：由于无刷新，这样会导致Css设置的失效。但是这样的问题可以使用多个AjaxPanel解决，并且效果一样很好。另外一个：对于无数据变化的相应，MagicAjax会报告一个Bussniss Busy的Bug，但是实际上并没有产生什么影响，我也觉得很奇怪。

不过这样两个Bug并不影响我使用它。而Atlas则是真的让人火大。我尝试过将他们放到一块，但问题出像了，AtlasPanel可以放在MagicAjaxPanel中，但是放过来就会报告错误，并不能让体统运行。无可奈何之下，大部分对数据的操作，我都使用了MagciAjax，与我最开始想的完全使用Atlas有点事与愿违了。

请注意，目前我只是讨论它们两个的关于UpdatePanel的比较，并没有比较别的组件。在别的提高用户体验的方面，Atlas的一些组件着实是很好用的。可以大量的和TextBox结合使用，您可以在我的一片文章里面回复，让后就可以看见效果了。而对于对GridView和Datalist的操作，我还是使用MagicAjax，因为着实是好用！在选择的时候大家可以参照一下上面所述，然后适当的选择合适的组件和方法。如果有什么问题，请在下面发表回复！