在这里我将试图考察一下目前.NET平台的下的Ajax框架,我也试图从中总结出来一种方法,使得你可以在众多基于.NET平台的Ajax框架和工具包中找到你所合适的一种,同时也希望你在考察、预研和使用这些流行的这些Ajax-NET 的框架时,做得理性和有的放矢。
我想,文章的方法会给目前使用Ajax的.NET用户带来帮助,从而提高你在.NET平台下使用Ajax的体验。为什么这么说,因为最近我的一个客户(应该是一些客户)的研发主管对我说,我们对Atlas 非常兴趣,想了解更多一些相关的内容和如何开始看待Atlas,因为下个月会来一个Atlas的专家和我们交流。因为我知道这个主管手上掌握着一个Ajax架构的业务应用,目前在考虑从.NET v1.1迁移到.NET v2.0,Atlas能在怎样的程度上帮忙他或他的Team?我没有说太多,因为心里我有些吃惊,目前的他们的架构应用Atlas 可能并不是一个明智的选择,当然这个担心基于我目前对Atlas的理解。
我列举和讨论的Ajax-NET的框架和工具包括Atlas(Jan CTP), Anthem.NET, MagicAjax.NET , Ajax.NET Professional 和wwHoverPanel Control,这基本都是我关注的.NET平台的下的Ajax 的一些框架和实现。 基本上也都是我的这篇文章中列举的,另外一个原因是因为他们基本上都是开源的,这个非常重要,因为没有源代码,我们将不知道究竟发生了什么。另外我无意于使之成为像Daniel Zeiss作的这个比较报告。
首先,开门见山的说明我的观点。
对于开源或现有的Ajax-NET技术或框架的选用必须针对你目前应用的架构来选取和考虑,如果你目前的架构是"似Ajax"的,那么你在选择现在所有流行的Ajax-NET的技术的时候都必须非常小心;而如果你目前的应用是使用传统的ASP.NET的应用架构(或准备用ASP.NET v2.0开始创建新的应用),那么目前流行的Ajax-NET的框架和技术都是普遍适合的,关键你要在合适的时机选择合适的某个框架或实现。
在我的眼中,目前流行的Ajax-NET的框架或实现都是Add-in (Plug-in)的模式的,也就是说这些框架对于所有后一种即使用传统的ASP.NET的应用架构(或准备用ASP.NET v2.0开始创建新的应用)是Awared的也就是非常有利和方便的。但对于"似Ajax"的架构来说,情况有所不同,需要你从另外的角度来衡量,有选择的使用。
那什么是"似Ajax" 的架构呢,这就是说,你的应用程序是在Ajax概念提出之前就创建的。从客户端和服务器端的交互分析来说,你的客户端有大量的Javascript 代码接受XML数据,进行对象的序列化,然后使用Javascript配合其它的HTML技术展现这些对象和数据,也可能你还有一堆HTC或其它的Javascript的HTML表现层控件。你的服务器端是一个Facade(或者是Adapter,Observer)模式的(Handler)控制器,接收客户端Javascript的XML请求数据后,然后解析XML,然后调用相应的某个服务或业务组件,再将结果以XML的形式返回给客户端Javascript ,客户端的Javascript接收之后,再进行处理和显示,因为可以使用HTML的DOM 和CSS,所有页面的展现是动态的。
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/webkaifa/)这样客户端是Ajax in Action中描述的Script-centric architecture 或Data-centric interactions 的方式。而且这种方式和Jesse James Garrett列举的Ajax 是最类似的,只不过那时你或我不知道这个可以叫Ajax,只不过是现在的人误解了Ajax,Ajax成了一种技术,一种特性,而首先不是一种某种架构下Web 应用了。
而且目前流行的Ajax-NET的框架基本上都没有实现双向序列化,因为实现一个TextBox的自动完成客户端只用接收数据就行了,根本不用传回数据/对象到服务器端,同样做一个Ajax的状态进度条也不用,但这些都是Ajax啊,我们衡量的标准是异步的、页面没有刷新。
很抱歉,我用了这么字才解释完我的观点。最后可以这么说,如果你的应用已经是Ajax架构的,那么你需要仔细选择使用目前的Ajax-NET框架,确保它也提供双向序列化功能,兼容你原来的应用和架构。如果你的应用不是Ajax架构的,那么你可以依据一些条件来选择Ajax-NET框架。
然后我们回到文章的开始,来看一些流行的Ajax-NET框架
1. MagicAjax.NET
这是目前框架中版本号最小的一个Ajax-NET实现,许多人很喜欢它,甚至一见如故,但真的看过它的代码之后,我有些担忧。
MagicAjax.NET基于这样一种策略,即__doPostBack 会提及整个的ASP.NET页面,这样会导致页面刷新,所以MagicAjax.NET使用AJAXCbo.DoPostCallBack 做局部的提交,而每个AjaxPanel 中的内容则对应客户端即时的HTML内容,因为在MagicAjax.NET中,客户端只用执行eval(responseText) 服务器端Rendered返回的HTML就可以了(很被动)。
由于DoPostCallBack 会提交ViewState 以及AjaxPanelx$RBS_Store,几乎是用XMLHttpRequest 模拟一个正常的提交,所以服务器端可以创建页面的实例也可以根据ViewState 恢复所有的控件状态,同样AjaxPanel 以及AjaxControl 也都会实例化,然后接收客户端传来的_EventTarget, _EventArgument 走正常的ASP.NET控件的处理过程,等控件Rendered之后,最终的HTML输出被传回客户端,然后被客户端的eval 显示出来。
整个过程非常巧妙,这几乎是ASP.NET __doPostBack 的"Hook ASP.NET"版和加强版本。而HttpModel 主要是为了解决Session和交叉提交,进行客户端Javascript的整理和注入,当然也是这里接收客户端的请求,在Application_EndRequest中返回结果。剩下的代码都是处理控件在VS Web Design中的设计时支持。AjaxCallObject.js 和WebParts.js 每次都要传到客户端。
MagicAjax.NET 的一些不足和想法:
1、__doPostBack 的加强版,适合于ASP.NET的高级用户使用
2、由于和ASP.NET的页面处理机制依赖非常密切,控件的默认动作发生变化则可能不工作,比如第三方的某个自定义控件;
3、依赖ViewState ,如果是加密的ViewState,则可能工作不正常,我没有试,在代码中好像没有看见__VIEWSTATEENCRYPTED
4、是对ASP.NET 全部页面提交的优化,实现有限的Ajax功能,可扩展性不大
如果是基于ASP.NET 提供的控件和开发,那么MagicAjax.NET 是非常有效的,很好的解决了Session和跨页面状态的问题。而且客户端的操作和工作基本可以忽略,MagicAjax.NET设计贴近最近的ASP.NET的版本,目前不提供调用客户端直接调用页面的方法。但随着其发展,优势可能渐少,因为Atlas 最新的版本提供类似的UpdatePanel 控件。
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/webkaifa/)