When ASP.NET programming model(s) gives you lemon

The default programming model of ASP.NET encourages us to do everything on server-side. That is, events and view modifications are done on C#. UpdatePanel encourages that more as this can prevent full page refresh


However, UpdatePanel is not a silver bullet, you'll encounter performance problem with it soon enough


So here are the ways ASP.NET communicates changes between server and client, listed from the least desirable approach up to the modern approach:

Built-in approaches:

• Post back
• Full page refresh
• All resources(image, css, etc) are reloaded, and view states are reconstructed too
• UpdatePanel
• No full page refresh
• However, all view states (even the ones outside of UpdatePanel) are re-sent back to server. Bad to network load
• All view modifications done from the server are received back by the client. Bad to network load
• All changes on form inputs are received back by the server. A good thing. Callback can't read changes to inputs done by the user
• Not so leaky abstraction. Simplest to implement, as ASP.NET WebForms' programming model is still maintained, e.g., the events and view modifications are still done in C#, not in JavaScript
• The programming model of ASP.NET WebForms was the selling factor of ASP.NET when it was introduced, VB6 coders can feel at home with the programming model of WebForms as the code looks like VB6 or WinForms
• Callback
• No full page refresh
• However, all view states are re-sent back to server. Bad to network load
• View states re-sent back to server are of limited use, can modify them at the server-side, but won't be received back by the client, essentially making the view state a read-only thing. This is a bad thing as this would make us use javascript for UI stuff instead of doing everything in C# (ideal programming model); this is good for network traffic though
• However, as view modifications done on server is of no use client, we have to turn to javascript to reflect back the changes to view, a leaky abstraction
• User-changed values in form inputs (e.g., textbox) can't be read back on server. When the user change the value of text, the server side can only read the initial value of textbox, can't read the new value. This severely limits the use of view state re-sent to server. This might compelled the developer to use again the UpdatePanel
• Complex to setup, see: http://msdn.microsoft.com/en-us/library/vstudio/ms178208(v=vs.100).aspx
• WebMethod (the best way if ASP.NET Web API is not available to your project)
• No full page refresh
• No view states are re-sent back to server. Good to network load
• The client won't received back any view states. Good to network load
• Leaky abstraction, we have to turn to javascript when modifying the value of the controls
• Easy to setup
• ASP.NET Web API
• Similar to WebMethod
• ASP.NET Web API just have richer functionality, e.g., it can bind the JSON sent to it to strongly-typed model

Commercial approaches:

• ASPxCallbackPanel
• Virtually similar with UpdatePanel
• ASPxCallback
• All the view state are re-sent to server. Same as the built-in Callback
• User-changed values in form inputs (e.g., textbox) can be read back on server. A good thing. The built-in callback can only read the initial state of the inputs
• The view's values can not be updated at the server-side. To report back the changes to UI, use the control's ClientSideEvents to run a javascript that can manipulate the value of textbox, labels, etc

Demo code: https://github.com/MichaelBuen/PlayAspNetOptimization


Here's a sample network traffic on each approaches:

Built-in approaches:

	Sent	Received	Total
Post back	45,211	7,569	52,780
UpdatePanel	44,791	1,795	46,586
Callback	44,715	1,088	45,803
WebMethod	605	543	1,148
ASP.NET Web API	609	506	1,115

Commercial approaches:

	Sent	Received	Total
ASPxCallbackPanel	44,638	2,000	46,638
ASPxCallback	44,657	896	45,553

Happy Coding!