views:

135

answers:

1

Can you help me make sense of all the different ways to communicate from browser to client in ASP.NET? I have made this a community wiki so feel free to edit my post to improve it. Specifically, I'm trying to understand in which scenario to use each one by listing how each works.

I'm a little fuzzy on UpdatePanel vs CallBack (with ViewState): I know UpdatePanel always returns HTML while CallBack can return JSON. Any other major differences?

...and CallBack (without ViewState) vs WebMethod. CallBack goes through most of the Page lifecycle, WebMethod doesn't. Any other major differences?

IHttpHandler

  • Custom handler for anything (page, image, etc.)
    • Only does what you tell it to do (light server processing, light traffic)
    • Page is an implementation of IHttpHandler
    • If you don't need what Page provides, create a custom IHttpHandler
    • If you are using Page but overriding Render() and not generating HTML, you probably can do it with a custom IHttpHandler (e.g. writing binary data such as images)
  • By default can use the .axd or .ashx file extensions -- both are functionally similar
    • .ashx doesn't have any built-in endpoints, so it's preferred by convention

Regular PostBack (System.Web.UI.Page : IHttpHandler)

  • Inherits Page
    • Full PostBack, including ViewState and HTML control values (heavy traffic)
    • Full Page lifecycle (heavy server processing)
  • No JavaScript required
  • Webpage flickers/scrolls since everything is reloaded in browser
  • Returns full page HTML (heavy traffic)

UpdatePanel (System.Web.UI.Control)

  • Control inside Page
    • Full PostBack, including ViewState and HTML control values (heavy traffic)
    • Full Page lifecycle (heavy server processing)
    • Controls outside the UpdatePanel do Render(NullTextWriter)
  • Must use ScriptManager
    • If no client-side JavaScript, it can fall back to regular PostBack with no JavaScript (?)
  • No flicker/scroll since it's an async call, unless it falls back to regular postback.
  • Can be used with master pages and user controls
  • Has built-in support for progress bar
  • Returns HTML for controls inside UpdatePanel (medium traffic)

Client CallBack (Page, System.Web.UI.ICallbackEventHandler)

  • Inherits Page
  • Takes only data you specify (light traffic) and optionally ViewState (?) (medium traffic)
  • Client must support JavaScript and use ScriptManager
  • No flicker/scroll since it's an async call
  • Can be used with master pages and user controls
  • Returns only data you specify in format you specify (e.g. JSON, XML...) (?) (light traffic)

WebMethod (System.Web.Service.WebService)

  • Considered legacy technology. Should use WCF service instead.
  • Class implements System.Web.Service.WebService
  • Takes only data you specify (light traffic)
  • Server only runs the called method (light server processing)
  • Client must support JavaScript
  • No flicker/scroll since it's an async call
  • Can be used with master pages and user controls
  • Returns only data you specify, typically JSON (light traffic)
    • Can create instance of server control to render HTML and sent back as string, but events, paging in GridView, etc. won't work

PageMethods

WCF Service

Any others?

+2  A: 

WebMethod is used with ASMX web services, which Microsoft now considers to be "legacy technology". WCF services should be used instead. They support both SOAP over HTTP/HTTPS and REST-based or JSON services, so are much more flexible.

For this reason, I also recommend against PageMethods, even if they seem to be convenient.

John Saunders
Very good point I hadn't even considered in this case.
Nelson