views:

78

answers:

4

I am working on a Railway Portal and would require maintaining a shopping cart of components user has selected, there could be multiple components of different type in the cart. I don't see a value in storing the cart in database, would like to store the final order in DB. Where can I store/hold (temporary) the cart data per user session in MVC? All MVC samples I saw online save the cart data in DB – not sure why.

MVC presentation layer will be communicating with external web services for pricing and availability of these components, so I can't store only the product IDs to do a lookup for actual product descriptions/prices during the shopping process... I have to store everything in the cart (Product IDs, Descriptions, Prices etc) some place in memory. My application will be running in WEB FARM environment and cannot use in-process session storage. Options come to my mind are:

  1. SESSION STATE in SQL SERVER
  2. Using some kind of Distributed Caching Mechanism to store Session data such as “Windows Server AppFabric”
A: 

The cart is stored in the database so that it may be persisted across sessions if desired.

Additionally, by storing it in the database, you gain additional info that you can query against, such as Which items do my customers want that they have not purchased yet?

Even if you don't want that feature now, put it in the db, as addding that functionality later will be much more difficult, while it is fairly easy to do upfront.

RedFilter
Alex
Storing in Session is still putting the cart in the database if you use `SqlServer` sessions (which I recommend). It actually adds an additional serialization component to the task storing in session, so is arguably slower.
RedFilter
So...storing the cart data in DB and a corresponding GUID in cookie (to retrieve the cart) would be better then using SESSION STATE in SQL SERVER because later would do the same thing with an overhead of serialization. If I am able to figure out and leverage AppFabric, would it be a better option then storing cart in DB?
Alex
+1  A: 

It's always an option to store this data in an encrypted client cookie. Ruby on rails does this and it scales very well.

See http://agilewebdevelopment.com/plugins/encrypted_cookie_store for more details on how Ruby does this. Don't know how you would implement this with ASP.Net MVC.

Pieter
If you use encrypted cookies you need to be very careful about the size of the cookies, once you start exceeding 1KB really bad things randomly start occurring on your site.
Chris Marisic
Absolutely, this is not trivial. Another thing you really have to think about is encryption. See http://stackoverflow.com/questions/667887/aes-in-asp-net-with-vb-net for a good explanation.
Pieter
A: 

Shopping carts are perfect matches for document databases. I would recommend looking at RavenDB, Redis, MongoDB, CouchDB for starters.

If you want extreme performance your notion to use App Fabric is already there, after that you can persist the cart to any durable store since performance is a relatively moot point then.

Chris Marisic
Thanks Chris, I'll explore more on App Fabric because I would like to leverage extensive caching in my application to avoid number of calls (judiciously) to external web services. I am hoping App Fabric would also work for storing shopping carts per user session and be available in web farm.
Alex
I haven't worked with App Fabric yet but your last statement is the entire reason it exists. The reason I brought up document databases is using them you might not need to implement caching at all for the shopping carts because these stores are developed to serve under that load with no sweat with the correct application of the technology.
Chris Marisic
A: 

Although it is tempting to store the cart in a hidden field as an encrypted string, this would be wrong, as most users would expect their cart to retain its state.

Imagine if amazon's shopping cart didn't persist over sessions. They would not sell nearly as many books, electronics or whatever.

When in doubt, take a look at an equivalent site that is successful and see what they have done. This applies to all things in life, not just websites.

awrigley
PHP had a flaw until very recently where the session cookie used a very simple random number generator that could be reduced from 140 bits (or something) to 20 bits. The rest could be guessed. Success isn't always a good measure of correctness :) (and be careful with ID cookies!) http://www.youtube.com/watch?v=XQcW1zYiqdU
Rei Miyasaka
Who said I was promoting cookies for this? What has you comment got to do with my answer?
awrigley