ASP.NET: Links are often better than Postbacks

Craig mentions a reason to avoid links, and Eron follows up by wondering postback or links -- well here's my take:

I prefer links instead of postbacks.  First, they work for all browsers, and small devices and phones are becoming more common.  Next, the race conditions with postback/viewstate are very common and quite serious.  I can't count the number of times I've approved the wrong post on the ASP.NET forums due to this very type of issue.  If the ASP.NET forums can't get it right, do you really think your common developers can?  This is very common among any high-use ASP.NET apps, although no one ever seems to acknowledge it.  And its so easy to fix by using links, which also can allow you to avoid using response.redirect, let alone server.transfer which is terrible in the state it leaves the browser history.  Speaking of history, links also allow you to set favorites, and also allow your users to use the back button.  Hmmm, so links work in all browsers, give better consistency, allow setting of favorites, don't confuse history, and support the back button . . .   Its just amazing to me that so many people have just bought into the postback model for so much.  Yes, its great for events when you need them, but that doesn't make it a panacea for all things.  And to the original issue -- I'd hardly call that a reason to avoid links -- that's just a reason to avoid stupid links, or at least unsecured stupid link!

4 Comments

  • Craig's reason for complaining about links is actually a design flaw of Wiki, not a problem with links themselves. Wiki's problems with spiders such as google can be solved with a robots.txt file or a META tag. However, then the page won't get indexed by google. Thus, Wiki's design flaw.

  • Not all robots respect robots.txt or the META tags. I agree that it's a design flaw of the site, though, which is why we changed the rollback feature to be a button. There are, of course, other ways to handle it, but in general one should assume that any link on the page can and will be visited by something other than a human.

  • I totally agree, Paul... i hate seeing code that postsback only to response.redirect immediately... seems horribly inefficient...

  • A reader asked by email for clarification:



    I don't know if "race condition" is a good description, but I went with that term since that was what Eron called it. Here's what Eron says in his comments:



    Postbacks within DataGrids do not exhibit the race condition if ViewState is enabled and the DataKeys collection is used. Another solution is to persist the DataKeys collection outside of the DataGrid control itself; in that way ViewState can be disabled for the grid as a whole but the keys are tracked.



    I couldn't say it any better. Basically, if you disable viewstate, which is common on grids since the viewstate is so large, then things can get out of sync if data is changing. The postback simply says to do something (approve or delete or whatever) a certain item in the grid by its position -- and that position may not be the same if the data has to be requeried! I've actually even deleted the wrong post in the forums because of this. As Eron noted, there are other solutions, although most people either have very large viewstates with grids, or disable it and potentially get things out of sync.

Comments have been disabled for this content.