2. 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() 事件中处理和返回请求的结果。
2.1 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) Anthem.NET 也是一种"Hook ASP.NET"原理，旨在弥补ASP.NET的整页面的提交和PostBack，并且在客户端的数据访问和交互上做了加强。
2) Anthem.NET需要重新将ASP.NET提供的控件进行继承和包装，所以使用和功能的兼容性上非常敏感。
3) 也许微软下个版本的ASP.NET的标准控件可以借鉴Anthem.NET的做法，给各个控件增加这个远程回调的接口。
4) 目前版本的功能已经非常强大和略有些复杂了，而且部署比较方便，无需设置HTTP Model。
3. 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的框架都不支持这个功能。
目前在wwHoverPanel 的场景中，我认为这是一种轻量级的实现，对于多层嵌套多组引用的对象图类型或是大规模容量访问压力下，客户端和服务器端都还需要优化，所以如果其作为Ajax架构，客户端和服务器端通信和传递数据的通讯层上，显然是有些单薄了。
wwHoverPanel 的一些不足和想法：
1) 该控件是目前我见过.NET平台下，惟一同时支持客户端回调和页面方法调用的Ajax 控件，同时又支持两路双向的序列化。
2) 相对来说，wwHoverPanel是设计最简单的一个，而且是基于控件不依赖HTTP Model和ASP.NET Page Pipeline，也不依赖ViewState
3) 该控件能够让你在Ajax特性实现的技术层面上，能够在客户回调和客户端调用页面方法两者中取得平衡。
4) 目前的客户端回调支持其它页面的回调，但是其结果输出需要输出原始的HTML，这个影响应用的分层和设计。
5) JSON的双向序列化是一个不错的方案，但高性能的场景下，应该考虑实现更高效的序列化框架
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）4. Atlas
这个产品，我就不列举具体的功能了，而主要说一下我对其的看法和持有的态度。因为在我的Ajax书评中提到过问题。
Atlas 是一个个性鲜明的产品，其优点是明显的，缺点也是明显的，但首先你必须认识到它还是一个比较复杂，拥有较高学习曲线的解决方案。对于其复杂性，老实说目前，大多数人还缺乏真实的感受。
最近的一个个版本-Jan CTP，我们看到了一些特性，其强大之处在于：
1.客户端(Javascript)的数据绑定、校验带来便利。
2. 新的Update Panels不仅拥有了MagicAjax.NET 的特性，而且功能更强，是目前Atlas中异步回调的主要控件。
3.内置了一些具体Ajax特性的控件，比如AutoCompleteExtender ，DragOverlayExtender
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）4. 提供了一些使用的控件比如，ScriptManager, Triggers ,TimerControl
5. 主要用途着重在提供一个客户端控件和服务器端控件的特性集成的方案和容易使用的开发效率上。
但缺点也是明显的，比如：
1. 客户端的Behaviors还很弱，模板(Templates)和UI增强(UI Enhancements)功能还没有看到。
2. 所谓的客户端Atlas控件(“Atlas” Client Controls)和服务器端的Atlas控件(“Atlas” Server Controls) 还没有一个明确的规范，所以现在你基本上还不能创建自定义的Atlas控件(无论客户端还是服务器端的)。
3. 目前还只支持调用Web Services的服务，对于ASP.NET的内置的服务以及WCF的服务支持也没有看见，也不支持页面或控件内的方法调用
4. 功能上还不稳定，一些功能仅是在特定条件下的特性实现，还不能满足部署生产环境的要求。我认为，如果Atlas发布Go-Live License，那么可以考虑Atlas的放入到正式的项目或应用中。
我并不建议，你现在就将它应用在一个老的ASP.NET 项目中，或是老项目迁移到ASP.NET v2.0时优先考虑它；更多时候，如果你是创建一个新的ASP.NET应用，而又跨越了其学习曲线的情况下，可以考虑使用它。目前的情况下，对于Atlas，我建议，你应该保持足够的关注和实践学习，但是要抑制住将其应用到项目中的兴趣；因为Ajax，你现在可以开始关注和学习它，但是你不能因为要实现Ajax一个特性，而立即选择Atlas，那么是可能有风险的。
注： Atals 的Microsoft.Web.Script.Serialization 命名空间中有JavaScriptObjectDeserializer和JavaScriptObjectSerializer两个对象，第一，我不确定其是否也是JSON 序列化，而且我也不确定目前是否支持两路双向的序列化；第二，目前的版本，我还不能进行自定义或扩展，同时也很难对于其性能做任何的结论。
