views:

546

answers:

7

What is the most standard or best way to persist data between requests?

Should I use cookies or session variables? I'm interested in keeping data like sort order, sort column, and page number (for paginiation).

I'm coming from a webforms background so normally this type of thing was automatically handled for me in the viewstate of the controls I was using.

update

I like the querystring idea, for searching and more meaningful URLs; however, I'm working on an "index/list" view, which consists of a View with header, and "control" options, like DDLs for filtering and a partial view that renders the table of data.

The DDLs use a $.load() to call an ActionResult on the controller, which returns the partial view, passing parameters there in the querystring, but since these are ajax requests the main page url of the user's browser does not get updated.

Is there a best-practice for taking querystrings off the main-page URL and using them in ajax requests to other ActionResults?

A: 

Session are easiest.

Dustin Laine
Page number in session? How do you link to page 5 of a list then?
jfar
create/update session on page load based on URL.
Dustin Laine
A: 

It depends on how permanent you want the information to be:

  • Things like the page number should indeed be in the URL (as others have pointed out) - this helps with bookmarking, etc, but remember that if you add more content to the list, then that bookmarked result set will not always be what the user wanted...
  • If you're happy for these values to be lost when a session times out (by default around 20 minutes), then put them in Session.
  • If you think that sessions are going to timeout before the next request, or you want to save it across visits then you should be storing them in either cookies, or a profile (potentially allowing "Anonymous" profiles, which work with the users cookies, so they would lose them across machines).

Personally, I'd think very carefully about putting sort order and columns in the URL if you do you could actually end up really confusing search engines:

  1. Lots of pages with very similar content (page 1, sorted by date desc, page 1 sorted by date asc, etc) - search engines don't like duplicate content, and nor should you as Google (for instance) will only show two pages from your site in a default result set, you want them to be valid, not duplicates.
  2. Search engines will spend lots more time crawling your site, and potentially give up - If on every page they find links to "Sort by this column", they will attempt to follow them, resulting in more work on the server, higher bandwidth use, etc.

These can be mitigated through the use of a Robots.txt file denying access to sorted versions of the page, but if this is generated almost dynamically that will be very complex to maintain going forward.

Zhaph - Ben Duguid
Page number in session? How do you link to page 5 of a list then?
jfar
Good catch with the page numbers, but sort order and column in the url are equally farcical.
Zhaph - Ben Duguid
@Zhaph - Ben Duguid - Users send each other pages all the time. Not allowing them to link to a page is bad UX design.
jfar
@jfar, agreed - I've updated my answer to include a note about page number, however I still disagree with sort order being url based to be honest... http://www.dabs.com/category/computing,pc-peripherals,webcams/11195/3#Paging (not my site) is page 3 of the list sorted Z-A, if you follow it, you'd just see page 3 with default ordering - But I wouldn't send you a link to a page of results, I'd send you a link to the actual product I thought was interesting...
Zhaph - Ben Duguid
@Zhaph - Ben Duguid I have traffic stats to back me up here. I've seen hits come in on sorted pages with the sort param in the url. The sort param would only exist if a user sorted. Presuming you know what your users are doing is dangerous especially when traffic stats can usually confirm behavior.
jfar
+2  A: 

A standard way is to pass those sort of things via URL Query Parameters. You can modify your routing to expect certain URL variables. That way the pages become more search engine friendly as well.

Turnkey
Hmm, not sure about them being search engine friendly with sort order/column in the URL - you potentially end up with lots of duplicated pages unless you're careful with your robots.txt file to exclude indexing of those pages.
Zhaph - Ben Duguid
Good point, I think it's better for pagination as Chad pointed out, but perhaps put the non-distinguishing parameters into the TempData.
Turnkey
+3  A: 

If you want it to survive only through one request/redirect TempData is your friend.

However, for things like your pagination, URL is the best method, for the ability to share links alone.

Chad Ruppert
I agree until it comes time to scale out. TempData relies on session, so you will have to augment your solution to include SQL shared session (which I believe works now in 2.0) or another session provider if you need to add additional instances of your application to a cluster. I personally try to avoid session altogether, opting instead to recreate everything I need with each post/put, etc.., but realize it is sometimes necessary.
Hal
Session has its place. There are a ton of ways to do this. Besides, how many actual websites have to scale that far out that hosting session out of proc in the DB becomes an issue?
Chad Ruppert
A: 

Things that were previously in viewstate should probably be put back in the clients hands via either hidden fields or cookies.

Session is "too" easy. In a dev environment it works great, pretty much no matter what you put in it. In production scalability and persistence become a problem. In-process session is likely to disappear unexpectedly if you have crashing bug in your site, and requires server affinity when load balancing. Out-of process session fixes the durability and affinity issues, but can still be a performance bottle neck if too much stuff is put in session. A VERY common problem is that each page will put 1 or 2 items into session but never take them out again when they are done. And even if a page removes it session data when it is no longer needed, the data can still get orphaned if a user starts a process and never completes it.

ScottS
A: 

Use cookies, session is not as reliable... You can also check this third party product if you are interested in a robust solution:

http://www.scaleoutsoftware.com/products/session_server.php

Ricardo
+1  A: 

In response to your update, a nice way to achieve that for pages would be to have links to "Previous" and "Next" pages of results (or better yet, a list of all pages in the list), output on the page, with the page numbers, that you then hide with JavaScript.

This way users should see your nice, AJAXy behaviour, and search engines (and users without JavaScript - mobile, or those using older screen readers for instance) will still be able to get access to all your pages - this will help your pages to degrade gracefully, or use "Progressive Enhancement".

Zhaph - Ben Duguid