net框架下的ajax

Ajax的崛起令微软感到有些尴尬，因为Ajax中的一些关键技术其实是微软在1997年发明的，可是该公司后来把它们搁置了。长期以来，微软一直几乎垄断整个桌面软件市场，但他对互联网软件却重视不够，以致在微软自己的asp.net沃土上培植出了形形色色ajax框架结构。他们中有微软自己的Atlas，Telerik公司的rad ajax，Michael Schwarz的ajax.net，还有最近国人开发的nbear等等。一时间群雄争斗，难分高下。但笔者认为随着微软对ajax的逐步重视，凭借其雄厚的财力，人力，以及他在浏览器方面独有的优势，在不久的将来将充分显示出他的霸气。

第一部分：基于asp.net的各种ajax框架

1. Atlas。这是微软大哥的产品。与生俱来的，它与asp.net有极好的融合性。它的目标就是整和客户端脚本和ASP.NET服务器端，全面支持ajax。它是一个完整的解决方案，所以最大的弱点是不能很容易地被老的Ajax架构的应用使用。他的早期版本，给我的印象就是：控件繁多，使用方便，但不够灵活，多个控件整合在一起会有或多或少的问题。

    Shanku Niyogi和Nikhil Kothari在PDC 2005上曾展示了下面这张Atlas的架构图：
    Atlas的整体架构分为客户端和服务器端两部分。客户端的框架和服务包括：封装浏览器之间差异的浏览器兼容层、包括一个javascript整套类体系的脚本内核、一个较为完整的基类库、一套组件及相应的组件模型和UI框架。服务器端框架包括：网络服务桥、应用服务桥、一个以ScriptManager为基础的服务器控件框架等等。Atlas力争使人们编写ajax应用程序与编写asp.net  Web Form应用程序类似。在服务器端将atlas的声明脚本发送给客户端，然后页面在atlas客户端框架下运行，使用atlas服务代理，客户端直接连接Web Service或Windows Communication Foundation （WCF）服务，给用户带来更丰富的客户端体验。

Atlas架构大大减少了开发者所需的代码量，进而提高了开发效率，因为服务器端控件已经为你生成了大量的代码。这种架构将页面中的内容、样式、行为和代码清晰地分开。客户端直接调用Web服务或WCF服务，这样就避免了使用中介层对通信效率的影响，同时也避免了增加中介层对应用程序设计、实现和部署中带来的复杂性。但也就因为他过分的依赖这些并不完全成熟和可扩展的服务器端控件，使得其灵活性大大减弱。微软一直把我们当成傻瓜，竭尽所能的为我们做所有工作。显然，这次他又失算了。虽然atlas嚷嚷的轰轰烈烈，但人们多半是把他当玩具拿来玩玩而已，还没有多少人敢用他来做真正应用的东西。相反，由Michael Schwarz自己开发的ajax.net却悄无声息的广为流传着，并且屡屡被人拿来做一两个小东西。原因很简单：ajax.net可以更好的发挥我们的能力，而atlas却只能更好的发挥微软的能力。

当然，上面说的是微软的早期版本。Atlas一直在进步，也越来越让我们喜欢了。今年9月份，Scott发布的Atlas命名和开发计划的文章，又给我们带来了两个好消息：

一．Atlas名称大变脸：

     客户端 Atlas Javascript Library 被命名为 Microsoft AJAX Library，它可以在任何浏览器工作并且支持任何Web 服务器。

     Atlas 服务器端功能被命名为 ASP.NET 2.0 AJAX Extensions,同时原来的 Atlas 控件标识 会被更改为 ，这些控件会集成到 ASP.NET 下一个版本。

      目前开源的 Atlas Control Toolkit 项目被命名为 ASP.NET AJAX Control Toolkit。

二．微软将在今年年底发布Atlas 1.0 Release版本，在这之前会先发布Beta版本，根据用户的反馈意见决定最终的发布日期。

      Atlas要有大动作了。客户端和服务器端的划分更加明确，这样我们将有可能更好的继承扩展他们。而名称的改变意味着微软ajax与asp.net的进一步融合。Atlas的明天值得期待。

2. ajax.net。由Michael Schwarz开发的一个库，实现从Javascript到服务器端.NET的存取。他把Javascript中的客户端调用传递到.NET方法，并返回到Javascript回调。他用属性标记方法，能缓存结果，具有完整的类支持，使用HtmlControls来进行输入和返回值，返回的数据类型可以是数据表，数据集，数据视图，数组和集合。

ajax.net依靠服务器作为中介来分发和处理请求。他的.net封装类依赖于客户端的请求对象，使用xmlHttpRequest对象，但将其封装，隐藏xmlHttpRequest的实现。其封装类是通过在.net的方法上增加AJAX属性标记来实现的，一旦被标记，AJAX创建客户端的javascript函数（这类似于客户端编写的javascript函数），并使用xmlhttprequest创建服务器代理，这个代理把客户端函数映射到服务器处理函数。

Ajax.net非常适合个人用户和小规模开发使用，服务器端只需要加上个attribute就可以用javascript异步调用这个方法了，非常灵活，且容易上手。本人非常喜欢这个框架，他可以很容易的和其他ajax框架融合起来，一起使用。但由于他毕竟是个人产品，所以没有提供出一套完整的ajax解决方案。

3.MagicAjax.Net。和ajax.net等相比，magicajax的方便和易用十分地引人注目。如果是基于ASP.NET 提供的控件和开发，那么MagicAjax.NET 是非常有效的，他很好的解决了Session和跨页面状态的问题。而且客户端的操作和工作基本可以忽略。

ajax.net框架参考了prototype.js这个纯脚本ajax框架，如果你注册了一个类型到ajax.net里，那么在输出到客户端的脚本里就会有ajax.net为你生成的javascript对象，开发人员就可以像调用服务端对象一样使用他，但如果需要显示什么东西的话，比如填充某个下拉框就得自己动手，操作dhtml。而magicajax则是另外一种思路：创造了一个ajaxpanel，只要把你要执行服务端事件的控件放到ajaxpanel里，magicajax就在后台将页面要提交的数据提交回去，交给IIS，再传递给注册在配置文件中的ajaxmodule，他会负责返回被其框架解析的脚本语句，来反映出服务器操作造成的变化，客户端eval一下就可以了。而如何得到实现这种变化的脚本语句就成为代码主要完成的工作。

在ajax.net框架下，我们需要注册一个公布给客户端的类，然后在客户端脚本里访问，然后再根据从服务端返回的数据自己控制客户端界面的改变，需要的代码量比较大。而在magicajax的框架下，我们甚至不需要写一行代码就实现了无刷新的网页。

MagicAjax.NET发展了asp.net的 __doPostBack提交整个页面的机制，他使用AJAXCbo.DoPostCallBack 做局部的提交，而每个AjaxPanel 中的内容则对应客户端即时的HTML内容。HttpModel 只是为了解决Session和交叉提交问题，他进行客户端javascript的整理和注入，接收客户端的请求，在Application_EndRequest中返回结果。正因为如此，有人称他是ASP.NET __doPostBack 的"Hook ASP.NET"版和加强版本。

由于DoPostCallBack 会提交ViewState 以及AjaxPanelx$RBS_Store，几乎是用XMLHttpRequest 模拟一个正常的提交，所以服务器端可以创建页面的实例也可以根据ViewState 恢复所有的控件状态，同样AjaxPanel 以及AjaxControl 也都会实例化，然后接收客户端传来的_EventTarget, _EventArgument 走正常的ASP.NET控件的处理过程，等控件Rendered之后，最终的HTML输出被传回客户端，然后被客户端的eval 显示出来。magicAjax这种储存页面的配置，几乎改变了web的编程模型，真正意义上实现了桌面程序模型的web编程。

MagicAjax.NET也存在一系列问题。由于和ASP.NET的页面处理机制依赖非常密切，控件的默认动作发生变化则可能不工作，比如第三方的某个自定义控件；过分依赖ViewState ，如果是加密的ViewState，则会产生些问题；他仅是对ASP.NET 全部页面提交的优化，实现有限的Ajax功能，可扩展性不大。

4．RadAjax。这个是telerik的产品，功能强大，在国外影响颇大，不过国内好像重视不够。他自称是第一款不用编码就能把asp.net AJAX化的框架。

整个框架主要由4个控件组成：AjaxManager，LoadingPanel，AjaxPanel，AjaxTimer。这其中既借鉴了MagicAjax.NET的很多东西，也可以看到atlas的影子。他为用户提供了调用web服务以及通过AJAX（异步JavaScript以及XML）请求获取信息的功能；完全支持Response.Redirect()；会话超时时自动重定向；完全支持EnableViewStateMac设置为假（false）的Server.Transfer；AJAX请求过程中，实效字段将会被排除在外；图像按钮（ImageButton）单击提供用户单击图像的XY坐标。

5．其他框架。

Anthem.NET的设计遵循这样的理念：既然ASP.NET的各个标准控件没有实现提交功能，那么我可以产生一个提交的接口，然后继承原来的标准控件，然后再实现这个接口，这样每个控件都可以向服务器端单独进行提交，而每个控件的发生过程类似MagicAjax.NET。和MagicAjax.NET不同的是，Anthem.NET没有容器的概念，因为每个控件都增加了提交接口，可以单独的提交，所以Anthem.NET每一次提交的花费更小些(但服务器端是类似的，因为整个ASP.NET页面的Pipeline都会进行)。同ajax.net类似，他也可以通过客户端调用页面中的方法并获得结果/数据，并且也支持多种返回对象。Anthem.NET 的一些不足主要是：他需要重新将ASP.NET提供的控件进行继承和包装，所以使用和功能的兼容性上非常敏感。
     wwHoverPanel AJAX Control for ASP.NET是一个ASP.NET的控件，但是提供了客户端回调(高级回调)、客户端调用页面方法，以及双向两路的序列化功能。，wwHoverPanel设计简单，而且是基于控件不依赖HTTP Model和ASP.NET Page Pipeline，也不依赖ViewState。 JSON的双向序列化是一个不错的方案，但高性能的场景下，应该考虑实现更高效的序列化框架

AjaxAspects是个可以用Javascript调用服务端WebService事件的引擎。他用标准的SOAP和WSDL进行服务端-客户端通信 ；用简单的类型和XML对象支持带参数的返回值 ；支持缓存和动作队列。

 

第二部分：理想中的ajax平台展望。

      Asp.net下的Ajax平台发展到现在，基本上已经形成了一些共识：ASP.NET控件形式成为连接服务器和客户端Ajax通信的主要形式和选择；客户端调用服务器端页面中的方法是Ajax的重要手段，使得客户端可以更加灵活的获得服务器端的数据；Ajax 要求有足够的力量关注前端的UI展现或开发，所以Ajax框架必须提供多样的客户端的实现以及Web UI

有的人说，目前流行的Ajax-NET的框架或实现都是Add-in (Plug-in)的模式的，也就是说这些框架对于使用传统的ASP.NET的应用架构(或准备用ASP.NET v2.0开始创建新的应用)是非常有利和方便的。而今后，最有可能开发出一套完整ajax解决方案的很可能是微软。

一个完善的ajax框架或开发平台，至少应该解决这么几个问题：表现层展现的问题；双向两路的序列化问题；传输时客户端和服务器端的数据安全问题； 性能问题； 国际化支持；搜索引擎的友好问题。ajax平台的开发绝对是一个复杂性颇高的系统工程，需要大量人力，财力的投入。

那么，ajax平台应该是什么样子呢？从使用者的角度，个人认为未来的ajax平台应该具备这么几个特点：

自动生成JavaScript基础库。Javascript对ajax的份量不言而喻，如果有这样一个Wizard，我们能够选择针对的浏览器平台、版本、完备的功能列表等，然后它就能帮我们生成一个已经优化了的JS文件。那是多么令人憧憬啊；

智能调试javascript。让我们不再畏惧js；

智能的CSS优化。让可重用css规则得到最大限度的重用，最好能够让我们鼠标点几下就一切ok了；

全方位的重构支持。不止javascript,还包括dhtml,css的重构；

界面操作可视化； 集成各种UI组件库；

当然，完善的单元测试支持也必不可少。

　　

就象有人描述的那样，未来的技术人员，将不用谈论什么Web 2.0，就可以清楚的表达Ajax的概念 ；未来的架构师，也不再认为Ajax是什么异步的XMLHTTP调用，是什么不刷新页面，它只是一种可以帮助他们Review应用程序的架构； 对未来SOA的爱好者来说，Ajax架构让他们能够站在面向消息的架构和系统上来看面向服务…….这就是我们所希望看到的。

.net框架下的ajax是这样，所有的ajax框架都应该是这样。