We have a new, great post-back model with ASP.NET.  In fact, I was using a similar model in ASP 3.  I would choose a course of action based on a querystring or form value.  I would post information back to the same page with an “action” querystring that described what to do next.  The model worked well then.  Now we have that model implemented for us.  With any new capability comes the question: “When should I use it?”  Certainly not all the time.  I can pass XML to SQL Server, but does that mean that I should do it for every single stored procedure now?  Certainly not! 

I am currently working on a page that modifies certain properties.  To save the data, I have a button that posts back, and I save the information.  I have a cancel button.  Should I use a postback with the cancel button?  When the user cancels, I just want to leave this page and discard any changed information.  I really don’t have any clean-up processing for this instance.  I could post back and do a Response.Write( ) or Server.Transfer( ), but do I really need to reload that whole form, and then execute the button event handler to leave the page?  That would be extra, unnecessary processing.  No, instead, I’ll just have the button do a javascript onclick event that modifies the “location.href”.  No unnecessary post-back.  More efficient. 

There have been several times where a simple hyperlink was much better suited for a task than a post-back.  Also, remember that post-back handling comes after the Init and the Load events.  So on a post-back, you reload all the old data before the post-back handling occurs.  In some cases, I pass a querystring value to a page so that it knows what it needs to do right from the start.  I can start doing work in the Init so that my usercontrols have the information they need in thier Load events. 

As with all new capabilities comes the design decision of when to use them.  With the up-coming Yukon release of SQL Server, I see some people putting all their business logic with the database’s CLR.  Again, we will have to really analyze when it is appropriate to write some managed code at the database.  Certainly not all the time. 

Even when new capabilities surface, remember tried-and-true methods that have worked for years.