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 控件。

    Ajax.NET Professional

    我没有看过Ajax.NET Professional 的源代码，但从例子中看得其支持调用页面的某个方法，以及返回对象，DataSet，DataTable的数据，我认为Ajax.NET Professional 的实现和Anthem.NET 原理是一样的，虽然Ajax.NET Professional 使用了HTTP Model，这个只是和Anthem.NET 一样，最终处理结果的返回处理上稍有不同不同。比较起来，Ajax.NET Professional 没有重新继承所有常用的ASP.NET控件实现部分提交的功能，所以可能Ajax.NET Professional 比较强项的是调用页面上的某个方法，并在客户端获得结果的数据，这个已经够实现大部分的Ajax的功能了。

    从这个层面上看，我认为 Ajax.NET Professional 是相对笨重和复杂了。Anthem.NET不使用HTTP Model，提供控件基本的局部提交，也提供数据层面的客户端方法调用。Ajax.NET Professional 的源代码似乎总是不想共享 ，这也是我不喜欢它的另外一个原因。
无论如何，大家都没有提供两路的数据交换，即客户端可以获得服务器端的方法并获得结果和数据，但是目前都支持将这些对象/数据修改之后返回给服务器端。 
    
     Anthem.NET

    目前是1.0版本，其设计理念是通过另外一个思路，遵循这样的理念--既然ASP.NET的各个标准控件没有实现提交功能，那么我可以产生一个提交的接口，然后继承原来的标准控件，然后再实现这个接口，这样每个控件都可以向服务器端单独进行提交。

    每个控件的发生过程类似MagicAjax.NET，Anthem.NET提供了各个控件Javascript端的提交函数－这等于也截取了 __doPostBack，之后Anthem.NET 还提供了完善的客户端的事件比如PostCallBack 和PreCallBack 这样的客户端事件，之后也将使用XMLHttpRequest 模拟一个传统的页面提交请求到服务器端，服务器端生成页面实例，这个过程和MagicAjax.NET一样，最后是将Rendered的HTML在控件的 Render() 事件传回到客户端，客户端控件的innerHTML被赋值，动态更新。

    和MagicAjax.NET不同的是， Anthem.NET没有容器的概念，因为每个控件都增加了提交接口，所以可以单独的提交，所以单位是以一个控件为单位进行一次提交， Anthem.NET的花费更小些(但服务器端是类似的，因为整个ASP.NET页面的Pipeline都会进行)。

    此外， Anthem.NET 还有另外的功能，就是可以通过客户端调用页面中的方法并获得结果/数据，这种情况下，你将调用Anthem_InvokePageMethod 方法，而不是Anthem.NET提供的默认各个控件的提交方法。这样Javascript的回调处理函数中的result.value 将可以获得调用的服务端的某个方法(该方法以[Anthem.Method]为标记)的执行结果，因为JavascriptPost的数据中有 Page/MasterPage/Control 了，那么服务器端很容易通过这个标识获得方法的地址，应用反射寻找[Anthem.Method]标记，然后调用，将结果返回到客户端。

    Anthem.NET支持返回对象，DataSet，DataTable和 WriteDataRow(WriteDataSet,WriteDataTable,WriteDataRow,WriteObject)，返回的是符 合是JSON规范的字符串，这样客户端的Javascript就可以使用这些对象了。不同于MagicAjax.NET，Anthem.NET 没有使用HTTP Model，所以结果是在页面的PreRender() 事件中处理和返回请求的结果。

    目前在wwHoverPanel 的场景中，我认为这是一种轻量级的实现，对于多层嵌套多组引用的对象图类型或是大规模容量访问压力下，客户端和服务器端都还需要优化，所以如果其作为Ajax架构，客户端和服务器端通信和传递数据的通讯层上，显然是有些单薄了。

    Anthem.NET 的一些不足和想法：

1) Anthem.NET 也是一种"Hook ASP.NET"原理，旨在弥补ASP.NET的整页面的提交和PostBack，并且在客户端的数据访问和交互上做了加强。
2) Anthem.NET需要重新将ASP.NET提供的控件进行继承和包装，所以使用和功能的兼容性上非常敏感。
3) 也许微软下个版本的ASP.NET的标准控件可以借鉴Anthem.NET的做法，给各个控件增加这个远程回调的接口。
4) 目前版本的功能已经非常强大和略有些复杂了，而且部署比较方便，无需设置HTTP Model。

    wwHoverPanel AJAX Control for ASP.NET

    wwHoverPanel AJAX Control for ASP.NET 这也是一个ASP.NET的控件，但是提供了客户端回调(高级回调)、客户端调用页面方法，以及双向两路的序列化功能。

    wwHoverPanel 吸取了MagicAjax.NET 和 Anthem.NET的优点，同时又结合了ASP.NET的客户端回调功能，是一个轻量级的Ajax组件。

    看待wwHoverPanel 最大的两个特性中的一个是用很简单的方式实现了一个HoverPanel Behavior，这个实现比目前Atalas的Behavior 要简单，作者Rick Strahl 也强调这个主要是结合他具体的应用，比如这里提供了一个小的HTML板，可以显示获得的结果信息。

    wwHoverPanel 也提供一个局部回调的方法，但是这点的实现上和MagicAjax.NET 以及 Anthem.NET完全不同，它是使用一个StartCallback的Javascript来组合查询字符串提交并且使用XMLHTTP发请求到服务 器的某个页面(由ServerUrl 属性指定)，之后这个页面将结果以Response.Write()的原生HTML内容返回。这个和ASP.NET的回调方法非常类似，而且还支持将请求 发到本页之外的ASP.NET并获得结果，所以它增强了原来ASP.NET的客户端回调的方法，即支持其它页面的回调。可以说，这是一种基于URL的客户 端回调。

    wwHoverPanel 提供的第二个功能是，客户端可以调用服务器端中的某个页面的方法(这些方法以[CallbackMethod]进行标识)，这种情况下，你要设置 EventHandlerMode="CallPageMethod" ，然后使用wwHoverPanel.服务器方法名(参数，参数，...，回调处理函数)的方式进行调用。这个其实使用的是一个Javascript的 CallMethod 方法，调用服务器端的请求。Javascript 的HandleCallback 则用来处理返回的结果，逻辑相对简单，尽管控件的innerHTML 也被赋值，但这个主要是为了维护作为客户端回调结果显示的小的HTML板的内容，否则就是调用页面中的方法了，那么结果就直接给客户端的回调方法了。

    特色三，就是我说的双路的序列化功能了，其实这个场景我们也非常需要，比如我们用客户端回调或XMLHTTP请求获得了一个定单对象，那么客户端修改之 后，我还想把它作为一个客户端调用的输入参数，返回到服务器端。这时候两路双向的序列化就需要了，因为这次服务器需要将Javascript的函数传了的 数据序列化成.NET的类。这也就是JSON的双向序列化了(主要代码在JSONSerializer.cs )，这也是我挺喜欢的一个功能，因为我对这个功能关注很久，但是目前流行的Ajax-NET的框架都不支持这个功能。