Wednesday, October 1, 2014

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!

No comments:

Post a Comment