1

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”
Alex
  • 833
  • 3
  • 15
  • 28
  • 3. Store it on your application server - in memory (if you have one) - that is if you use sticky load balancing. I would just store it in DB - it's a nice feature for regular customers that buy in batch. – Jaroslav Jandek Oct 20 '10 at 15:04

5 Answers5

1

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 van Ginkel
  • 29,160
  • 8
  • 71
  • 111
  • 1
    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 Oct 20 '10 at 15:47
  • 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 van Ginkel Oct 20 '10 at 15:49
0

Store cart detail in database and cart reference in cookie for identifying for particular browser/client.

e.g

tblCart (refId,proId,qty)

refId and ProId will be Primary key.

refId store in cookie

Shell
  • 6,818
  • 11
  • 39
  • 70
NAwaziSH Khan
  • 1
0

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.

D'Arcy Rittich
  • 167,292
  • 40
  • 290
  • 283
  • I agree with your suggestion that its helpful to study "Which items do my customers want that they have not purchased yet?" but as I said in my question, my applications talks to a external web service for querying these products and they maintain extensive logs and have a statistics tool for these kind of studies. My app will be heavily used and high availability and performance would be key for my application. Storing & Retrieving cart in/from DB for every component added/removed from cart concerns me for lot of DB hits and performance issues... suggestions pls. – Alex Oct 20 '10 at 15:11
  • 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. – D'Arcy Rittich Oct 20 '10 at 15:25
  • 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 Oct 20 '10 at 16:08
0

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
  • 32,487
  • 24
  • 164
  • 258
  • 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 Oct 20 '10 at 16:04
  • 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 Oct 20 '10 at 16:17
0

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
  • 13,481
  • 10
  • 83
  • 129
  • 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 Oct 31 '10 at 07:49
  • Who said I was promoting cookies for this? What has you comment got to do with my answer? – awrigley Oct 31 '10 at 08:40
  • I'm saying that in principle it's not a good idea to just emulate the successful, especially in this case. The cookies example is incidental, and clearly neither of us are promoting PHP. – Rei Miyasaka Nov 01 '10 at 02:53