Question

What is the 'page lifecycle' of an ASP.NET MVC page, compared to ASP.NET WebForms?

I'm tryin to better understand this 'simple' question in order to determine whether or not existing pages I have in a (very) simple site can be easily converted from ASP.NET WebForms.

Either a 'conversion' of the process below, or an alternative lifecycle would be what I'm looking for.

What I'm currently doing:

(yes i know that anyone capable of answering my question already knows all this -- i'm just tryin to get a comparison of the 'lifecycle' so i thought i'd start by filling in what we already all know)

Rendering the page:

• I have a master page which contains my basic template
• I have content pages that give me named regions from the master page into which I put content.
• In an event handler for each content page I load data from the database (mostly read-only).
• I bind this data to ASP.NET controls representing grids, dropdowns or repeaters. This data all 'lives' inside the HTML generated. Some of it gets into ViewState (but I wont go into that too much!)
• I set properties or bind data to certain items like Image or TextBox controls on the page.
• The page gets sent to the client rendered as non-reusable HTML.
• I try to avoid using ViewState other than what the page needs as a minimum.

Client side (not using ASP.NET AJAX):

• I may use JQuery and some nasty tricks to find controls on the page and perform operations on them.
• If the user selects from a dropdown -- a postback is generated which triggers a C# event in my codebehind. This event may go to the database, but whatever it does a completely newly generated HTML page ends up getting sent back to the client.
• I may use Page.Session to store key value pairs I need to reuse later

So with MVC how does this 'lifecycle' change?

Answer 1

I'll attempt to comment on each of the bullet points you mentioned:

Your master pages still exist in MVC and are used to provide a consistent layout to the site. not much new there.

Your content pages will become views in the MVC world. They still provide the same content areas to your master pages.

The eventhandling of webforms should not be used in MVC, instead your Controller classes and their action methods will handle loading your data into a "model" that gets passed to the view.

Although webform style databinding is possible in MVC, I find that it is not the optimal solution. Better to place your data in a model class and strongly type your view so that you have direct access to that model. Then its simply a matter of using the <%= ViewData.Model.SomeProperty %> syntax to access your data and display it in the desired locations. As for viewstate, my recommendation is to forget that it even exists.

Remember that one of the advantages of using MVC is that you have control over the HTML you send to the client. Embrace that power and try to find solutions that allow you to maintain that control. Webform controls attempt to hide the the html from you and as such make it more difficult to customize the html when you need to.

I would highly recommend JQuery or one of the other similarly powerful javascript libraries. But learn to use them to access the HTML DOM directly and avoid the id mangling issues of webform controls.

You can use jquery to hook into the dropdown selection on the client side and submit standard or ajax style requests. Those request can return new pages, redirects, html fragments or even JSON data that can be used to update the existing page.

The asp.net Session can be used as needed.