一篇不得不转的ajax文章：与asp.net相关的各种AJAX框架的比较（英文）-CSDN博客

Frameworks included in this comparison are:

ComfortASP.NET V0.45 (beta)
MagicAJAX.NET V0.2.2
ZumiPage V2.02
ComponentArt V3.0 Callback Control
ATLAS CTP December 2005
Telerik r.a.d.callback 1.5.2

First, let me explain why only these 6 Frameworks are included although there is a lot more AJAX stuff for ASP.NET out there. All the frameworks listed here have one unique AJAX feature: They allow updating page content without programming AJAX directly - i call it indirect AJAX programming - a compareable concept is called Hijax. To make it concrete: Direct AJAX programming would mean dealing with client scripts, DHTML, method proxies and so on... Another important property the framework must have is the ability to support non-AJAX controls and enhance them with AJAX features. Therefore, frameworks that supply only controls with built in AJAX-features (Trees, Grids, Lists and so on...) are not included in the comparison. Please forgive me and drop me a note if I forgot a framework that also allows indirect AJAX programming.

This is the first step of a comparison that may be extended in the future - depending on the feedback I'll get. Many thanks goes to the people that already gave me feedback!

Please notice that the investigated features are really not all of the interesting things these frameworks can do. The main criteria for the comparison were the features that can be compared to those that come with the ComfortASP.NET framework.

Some general words about indirect AJAX programming:
What are the possible concepts to get to that goal?
I personally found 2 main concepts how indirect AJAX programming could be done.

The first concept is the page based concept. The idea with this concept is to transport all page content to the client to display a 1:1 equal page as it would have been without AJAX. One challange of this concept is the support of client scripts that must always be refreshed as the whole page content is updated (and therefore resetted like in real ASP.NET) with every AJAX postback. It follows the rule: "there is no persistent client state between postbacks" - that's really a big difference to direct AJAX programming. I personally think that keeping application state away from the client in an ASP.NET application is a good thing.
Another challange with the page based concept is to reduce the size of the response. No one wants the HTML of the whole Page being sent in an AJAX response. The idea to solve this issue is to transfer only differences to the previous request in a consecutive response. This must be performed by the framework automatically to make any sense and so providing nearly the same benefits to the users as in direct AJAX programming. The only framework in this comparison that supports the page based concept is ComfortASP.NET.

The second concept is the control based concept. The idea is to transfer and update only the content of the changed controls. The benefit is, that the resulting page is updated partially and the client can keep the static areas of the page untouched. ComfortASP calls this concept "selective update" - in ATLAS it is called "partial update". OK, that sounds simple - but - how can I tell the framework which controls I want to update? Here comes the differences between the frameworks. One way is to "mark" other controls via a container control (typically a Panel control) for AJAX. This seems to be a common way to integrate indirect AJAX programming, because most of the frameworks support this concept. Another way is to "register" the controls (in code behind) for an update (ZumiPage does that) without any special container control. The third way is to directly render the HTML stream of the desired Controls into the response stream of the AJAX framework (ComponentArt Callback Control goes this way) by writing the required code.
I personally have already developed a customer specific AJAX framework (it's not available for the public) that does a fourth way of "telling" the framework which controls should be rendered - it has an a utomatic control change detection mechanism, that supports different detection strategies.

I really tested all of the compared features you see below, but I am not an expert for each single framework so I can't take any liabilities for the correctness of results you see here. If you find any incorrect statments, please contact me and I will correct it as soon as possible. Please attach a reference to the source of your information or any code that confirms your statement. If you have further suggestions for improving this comparison, just drop me a note.

General
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt Callback Control	ATLAS	Telerik r.a.d.callback
Version	V0.45 (beta)	V0.2.2	V2.02	V3.0	CTP Dezember 2005	1.5.2
Author / Company	Daniel Zei?/td>	Open Source	Amir Leshem	ComponentArt Inc.	Microsoft	Telerik
URL	www.comfortasp.de	www.magicajax.net	www.zumipage.com	www.componentart.com	www.asp.net	www.telerik.com
Versions	Demo / Free (registration required)	Free	Demo / Commercial	Demo / Commercial	Technical preview	Demo / Commercial
Pricing	-	-	$59 (single web site) $139 (web server) more licenses available	$349 (developer license) more licenses available	-	$399 (developer license) more licenses available
supported ASP.NET Versions	1.1 / 2.0	1.1 / 2.0	1.1 / 2.0	1.1 (? - no info found on website) / 2.0	2.0	1.0 / 1.1 / 2.0
Update granularity: Page	yes	-	-	-	-	-
Update granularity: Controls or Panel	yes	yes	yes	yes	yes	yes
Update granularity: direct AJAX	-	-	-	yes (but onyl via callback handler, no method proxies)	yes (via WebMethod Attribute)	-
Base Concept(s)	Automatically create difference between postbacks und use AJAX for hidden Postback. Updates whole Page or Parts on Client.	Use a "MagicPanel" for AJAX updates. Automatically render Panel contents.	Register Controls for AJAX based updates. Automatically render the updated Controls on Client.	Mark ASP.NET content with "Callback Control" and manually Render content in Callback Event Handler. Trigger callback event on client by self written script. Note: Only ComponentArt Callback Control is compared here!	Multiple concepts: - Direct AJAX Programming. - Declare / Design AJAX - Add control that provide AJAX features (PanelUpdater) Note: Only the concept based on PanelUpdater is compared here!	Mark ASP.NET content with "CallbackPanel". Trigger callback event on client by self written script via "RadCallback" control. Note: Only Teleriks "CallbackPanel" & "RadCallback" control are compared here. Other Telerik controls have built in AJAX features.
Browser Support (List may not be complete)	IE, Mozilla, Opera (but Opera does not support all ComfortASP.NET features), All other browsers are supported by fallback to classic ASP.NET	IE, Firefox, Opera (not offically supported, but example worked)	IE, Mozilla, Opera	IE, Mozilla, Safari	IE, Mozilla	IE, Mozilla, Opera
_____________________________	__________________________	__________________________	__________________________	__________________________	__________________________	__________________________
Integration
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt	ATLAS	Telerik r.a.d.callback
No manual deployment of separate script required 16)	yes	yes	yes	n.a. (client script is included in initial request)	-	-
HttpHandler 1)	yes	-	-	-	yes	-
HttpModule 1)	-	yes	-	-	yes	-
Integration by Page derivation	yes (optional way)	-	yes	-	-	-
Integration by code aggregation	yes (optional way)	-	-	-	-	-
Framework specific feature configuration in web.config 2)	yes	-	yes	-	yes	-
Minimal required code changes (Lines of Code) to original ASP.NET code for "Hello World" Example. 3)	12 LoC in web.config	2 LoC in .aspx file; 1 LoC in web.config	2 LoC in code behind	4 LoC in .aspx file; 4 LoC in code behind; 1 LoC client script	10 LoC in web.config; 5 LoC in .aspx file	6 LoC in .aspx file; 4 LoC in code behind; 1 LoC client script
Manager Control 4)	yes (optional: when designer support is preferred)	-	-	-	yes	yes (RadCallback Control)
Controls or declaration possibilities for additional AJAX features	yes (Srcoll Anchor, TransferBar, ClientEventTextChange, PanelUpdater)	yes (Magic Panel)	-	yes (callback Control)	yes (many features can be described declarative)	yes (comes with several AJAX ready controls, that can be combined with callback control)
downgrade to pure ASP.NET (without AJAX) without code changes 5)	yes (automatically, web.config or manager property)	yes (MagicPanel property)	yes (Page property, registered controls)	not possible without code changes	yes (Manager property)	not possible without code changes
Turn AJAX on/off at design time 8)	yes (web.config or Manager property)	yes (MagicPanel Property)	yes (web.config or page property)	-	yes (via PanelUpdater property)	-
Turn AJAX on/off at runtime in any event handler 9)	yes (via Manager Control property)	yes (but only in non-AJAX postbacks)	yes (but only in non-AJAX postbacks, call to Refresh() required)	-	- (only in PreInit)	-
ASP.NET compatibility
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt	ATLAS	Telerik r.a.d.callback
ASP.NET ViewState in AJAX postback 6)	yes	yes	yes	-	yes	yes
Visual Studio Designer Support for AJAX content 7)	yes	yes	yes	-	yes	yes
Update Inline HTML <% ... %>	yes	yes	yes	yes	yes	yes
ASP.NET Event Handlers are called in AJAX postback 15)	yes	yes	yes	-	yes	-
Correct handling of Image Buttons (with x/y coordinates)	yes	event only, no x/y coordinates	yes	n.a.	yes	n.a.
Execute Scripts included in content that is updated via AJAX 11)	yes	- (only in initial GET request)	- (only in initial GET request, scripts can be registered manually)	yes	- (only in initial GET request, scripts can be registered manually)	yes
Features: Traffic
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt	ATLAS	Telerik r.a.d.callback
Entire traffic for the "Hello World" example [Bytes] (pure ASP.NET without framework: 3.470 bytes) Sources for the "Hello World" Example see below.	7.544	23.102	24.910	8.600	175.623	19.487
HTTP Compression of AJAX Response 10)	yes	-	-	-	-	-
Automatically transfer only changes of HTML content 12)	yes (makes a real diff on HTML)	yes (control content granularity, fingerprints HTML WebControls and the HTML between)	yes (documented feature, but the property to switch it on was not available in the demo version)	-	-	-
Save ViewState in server Session	yes (ASP 1.1 only)	-	Yes	-	-	-
Features: AJAX Postbacks
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt	ATLAS	Telerik r.a.d.callback
Trigger AJAX postback via client events (without custom client script) 13)	yes (TextBox changes only)	-	-	-	yes (several triggers can be declared)	-
Trigger AJAX postback via timer (without custom client script)	yes (via PanelUpdater control timer property)	-	yes (via Page timer property & timer event)	-	yes (via separate timer control)	yes (via separate timer control)
Queue AJAX postbacks and wait for response when a previous request is in progress 14)	yes	- (new requests are posted while a previous request is still in progress)	- (new requests are ignored)	- (new requests are ignored)	- (new requests are ignored)	- (new requests are ignored)
Automatic fallback to postback via IFRAME if XmlHttpRequest is turned off (IE6: disable ActiveX controls)	- (fallback to pure ASP.NET is automatically performed)	- (no response in AJAX request)	- (fallback to pure ASP.NET is automatically performed)	yes	- (a javascript error occurs)	- (message box with "operation abort" appears)
Additional features
	ComfortASP.NET	MagicAJAX.NET	ZumiPage	ComponentArt	ATLAS	Telerik r.a.d.callback
Set Client Focus to input element (e.g. TextBox) in ASP1.1	yes	-	-	-	-	-
Scroll to a (with designer) defined position in the web browser after AJAX response	yes (via any existing Control or special anchor control for IE/Mozilla)	-	-	-	-	-
Optional features to prevent Form input while hidden postback is in progress	yes (disable form elements, hidden disable)	-	-	-	-	- (events OnRequestStart and OnRequestEnd may be used to implement this feature manually)
Update multiple contents parts (e.g. Panels) with a single AJAX request/callback	yes	yes	yes	- (each update requires separate callback)	yes	yes
Control content update at runtine (e.g. Update only 1 AJAX Panel, while 2 are existing)	yes (via PanelUpdater Control property)	- (no selection possible, all Panels are updated)	yes (via Control registration method)	- (each update requires separate callback)	yes (via PanelUpdater methd or conditional update triggers)	- (no selection possible, all Panels are updated)

1) Integration via an HttpHandler or HttpModule allow you to activate the AJAX additions within the web.config, e.g.:

<configuration>
<system.web>
<httpHandlers>
<add verb="POST,GET" path="default.aspx" type="{Framework assembly}"/>
</httpHandlers>
<httpModules>
<add name="ModuleName" type="{Framework assembly}"/>
</httpModules>
</system.web>
<configuration>

2) Some frameworks allow additional configuration of features in individual web.config sections. This allows you to control certain (mostly global) features without code changes.

3) The "Hello World" example is a simple web page that displays the server date in a label field after a button was pressed:

4) Some frameworks offer a manager control (or something similar) to provide designer and runtime control over specific features.

5) Not all of your clients may be able to use your AJAX features. For example if the browser simply doesn't support them. So it may become important to be able to downgrade to pure ASP.NET.

6) The frameworks compared here allow indirect AJAX programming. For ASP.NET it is important to handle the ViewState correctly, even in an AJAX request to be able to keep the current Server Side programming model without too many code changes.

7) The Visual Studio designer is one of the most frequently used tools to keep your productivity high. So Designer support - also for AJAX content - is a very important feature.

8) Turning AJAX on and off at design time is an important feature to help you finding bugs and AJAX problems. You can easily compare the content update with and without AJAX.

9) Turning AJAX on and off in any of your event handlers in server code.

10) Very often dynamic HTTP responses are uncompressed and transferred in plain text. Compression can save you in an average up to 75% of your HTML traffic, but it also produces a higher CPU load on your web server.

11) Updating scripts may become a big issue. Even for developers that focus on pure server side ASP.NET development. In many cases you have content that is generated by 3rd party controls that you cannot directly influence. And many of these controls are using client scripts to enhance the user experience. Although if your AJAX framework supports script execution you do not have a guarantee that all of the controls that utilize scripting will run without issues after an AJAX postback.

12) Automatically transferring only changes of the HTML content between two AJAX responses can save a lot of additional traffic but also produces a significant higher CPU load on your web server for the diff-calculation.

13) Triggering hidden postbacks while client events occur is one of the most interesting AJAX discipline. A client event in this context is an event that the server in a classic scenario normally does not get (e.g. a key up - event). A common usage for this feature is the update of content while the user types somthing in a TextBox. The updated content typically is refreshing "just in time" while the user is still typing. This can be used e.g. for suggestions, validation or secondary content update & filtering.

14) When the user triggers an action that results in an AJAX request while a previous AJAX postback is still in progress, the new AJAX request should be queued in a request queue and posted after the previous request returned. This is required because browsers normally limit the number of concurrent connections to the server (IE has only 2 by default). This is also required to be sure that the ASP.NET ViewState and the browser UI state is handled correctly with the order of user inputs.

15) When an AJAX callback is performed on an ASP.NET Page, it is very important that all the ASP.NET events are called as in a non-AJAX callback. Some frameworks force the developer to move parts of the code behind into framework specific event handlers, which makes downgrades back to pure ASP.NET impossible without code changes.

16) If the framework requires a separated client script, it makes deployment easier, if the script is provided by the framework automatically.

Transfer sizes of the "Hello World" example with ASP.NET 2.0.

You can see the "Hello World" example here (ASP.NET 1.1 Version that differs from the originally tested "Hello World" example, because I have no ASP.NET 2.0 web space).
The source code for all tested frameworks can be found here (ASP.NET 2.0). Framework DLL's and other framework sources are NOT included because of copyright.

Explanations about the "Hello World" example - why it is as it is:
The "Hello World" example consists of a Panel that shall be automatically transferred with AJAX with minimal coding effort by using the specific framework. Coding effort means here the changes that had to be made to the original ASP.NET code! Inside the Panel is a static Label, a Button WebControl and a TextBox WebControl. In direct AJAX programming (like with AJAX.NET) you would normally change the TextBox content directly by only transferring the Date String. But for this comparison other Elements are intentionally included in the AJAX content to let the framework decide what to transfer. We assume that in an indirect AJAX scenario it is typical that the developer does not mark all the AJAX controls at a very low level (include/exclude each single control), because of the development effort. Another requirement in the "Hello World" example was to let the AJAX content be positioned absolutely in the Visual Studio Designer like with the ASP.NET original Panel. While Telerik allows this by using the Telerik callback panel, other frameworks that are Panel based like MagicAJAX and ATLAS require an extra ASP.NET Panel around the AJAX content.

The transfer traffic of the "Hello World" example for each of the compared frameworks is listed below. For a better comparision to direct AJAX programming the traffic of the AJAX.Net Profrofessional AJAX framework is also included. To keep the influence of the ViewState small, it was kept on the Server by using ASP.NET's SessionPageStatePersister. But there is a small inconsistence with the Telerik callback control, because it did not work together with ASP.NET's SessionPageStatePersister (it threw a NullReferenceException). I had to turn it off to get the example to work. As the ViewState is transferred via the web client, the measured traffic with Telerik was slightly increased.

Here is a table of links for the monitored traffic (captured with Fiddler and IE6):
Capture of pure ASP.NET 2.0
Capture of direct AJAX programming with AJAX.NET Professional V5.11.4.2
Capture of ComfortASP.NET V0.4
Capture of MagicAJAX V0.2.2
Capture of ZumiPage V2.02
Capture of ComponentArt V3.0 Callback Control
Capture of ATLAS December 2005 CTL (via UpdatePanel)
Capture of Telerik r.a.d.callback V1.5.2

Diagram 1: Traffic in bytes for initial GET response