Still ok to use Session variables in ASP.NET mvc, or is there a better alternative for some things (like a cart)

Question

I have a situation where I need access to a shopping cart over several pages. So, on the product page - create the cart an add some items On the cart checkout page - confirm the billing address On the cart checkout post - do a final check, add cart to DB and go off to payment

My question is, whats the best way to pass around the cart?

I have tried passing the Cart from page to postback and keeping all the values alive, however on some pages (the billing address confirmation page) this seems like a lot of hassle, all I want to check is the billing address and dont really want tons of HiddenFor() on the page to populate the cart back again

TempData[] is what I used for the product to checkout page, then wondered is it best to keep on setting TempData all the time when....

you could just use a session variable?

For some reason I read its not great practice to use Session, hence the question.

Thanks for your guidance, I can happy provide some code/more info if you deem it helpful.

Answer 1

It is perfectly OK to use sessions in ASP.NET MVC, especially in the shopping cart scenario of yours.

There are drawbacks of using sessions, but they seem not to apply to your case:

1) The sessions prevent a user to properly browse your site from multiple browser tabs, the changes made in one tab are reflected in all others. But with a shopping cart, it's exactly what you need. You don't need several shopping carts per user, do you?

2) The sessions aren't persisted by default, and if you're operating on a webfarm, you need to save the sessions in your database to be accessible by every farm node. But it seems unlikely that you're scaling like this. And if you meet the scaling neccessity, sessions won't be your top problems.

3) Sessions require additional functionality from the user's browser (typically, cookies). But modern browsers all support cookies, so you only have to worry about very special browsers.

There are also some benefits of the sessions over hidden inputs:

1) The smaller overhead. Only a small session cookie is passed back and forth between you and the client, rather than the complete set of hidden inputs.

2) Simpler programming. You don't have to make sure you included your hidden inputs in every single one of your pages.

3) Security. The client can alter the contents of hidden inputs however he pleases. You can't easily pass sensitive information via hidden inputs, you need to encrypt it. Session values are stored on the server, so the client doesn't have access to them.

Answer 2

Sessions are fine, but consider the Amazon-style system whereby you are issued with a recognition cookie even when you are not logged in. This allows them to store your shopping basket in the database, keyed against the recognition cookie.

The result is that you avoid the horrible user experience of losing your shopping basket due to session timeout / server appdomain recycling (the latter is mitigated by using SQLState session storage, which I recommend). The user can come back days later and their basket will still be there. Unless that's a security / privacy problem, I find it the better solution.