This is a dedicated thread for discussing the SitePoint article ‘Building an ASP.NET Shopping Cart Using DataTables’
Great article, it was easy to customize the code to fit my requirements. Works just fine!
Storing all this data in the session object is a really bad idea if you ever plan to have the application scale well. Memory considerations aside, the casting back and forth from the session object introduces a lot of overhead. It gets even worse if you’re in a server farm and storing the shared session data in SQL Server. The worst problem though is that once the session is done, the cart is gone!
This is not an ideal solution.
the article helped a lot ,and cleared up my basics for the shopping cart.keep up the good work!!!
the article is nice but what will happen if to users access the page?
does it create different carts or same !!!
What’s the alternative? Storing everything in the database? Won’t that take up as much memory and overhead? Plus the network traffic? Plus, now you’ll have a bunch of abandoned shopping carts taking up space on your database that you’ll have to deal with.
IMHO, sessions make sense. Memory and CPU power is realitively cheap. If you’ve got so much activity going on that you have to upgrade your server, it’s because you’ve got a lot of shopping going on which means income to offset the upgrades.
Yes, keeping carts in the database is exactly what you should do. It won’t take up more memory, the overhead is not significant (casting data back and forth between its native types and session objects is an expensive operation, perhaps worse than hitting the database) and network traffic is not an issue in a world of gigabit connections. Abandoned carts are not a big deal if you have a running process to delete those that age beyond a certain time.
Sessions are one way to do it, but it’s far from an ideal solution. Buying more servers because they’re cheap won’t win the hearts of bean counters, and if you have a server farm then you’re storing session data in SQL, which is another performance issue on top of a performance issue.
I think it is a good way.
By keeping the cart in the session the updatiopns take place very quickly.
The customer does not have time.
So the quicker it is more will it attract the customers.
But their cart will go if they leave your site, I think it’s much more dissapointing for them than difference of some miliseconds in page loading speed.
Agreed. People grossly underestimate the power of SQL Server. Besides, if you’re a good little code monkey, you’re caching the cart anyway, so it doesn’t have to reload it on every hit, or at least until the cached version expires. I use this in my forum app extensively. An entire topic is cached in memory, I like to use five minutes, and it’s valid until the topic is edited or updated. That saves hundreds of hits to the database in the case of a busy site.
Actually, If I were doing this in a “real” application, I wouldn’t use Sessions and would probably lean to using SQL Server as the storage mechanism. However, my writing style is and always has been to present a solution that is easy to follow and as basic as possible. Besides, I would venture to guess that 85% of Sitepoint visitors are beginner to intermediate anyway. Learning something at it’s most basic level helps build confidence and allows the user to expand on the project and think for themselves which in turn builds more confidence. I’m never been the type of writer that likes to show off what I know in my writing…
Thanks for your interest in my article guys…I appreciate it.
I’m never been the type of writer that likes to show off what I know in my writing…
Isn’t that part of the point though? I understand that you want to make the article accessible and everyone needs to start somewhere, and I applaud that type of inclusion 
But… most good technical writing aimed at beginners will point out the shortcomings of their trivial examples and point the reader to some more advanced resource. Now, admittedly without having read this article I can’t criticize the author’s writing style, but I just thought that I would point this out. It did sound like a few users might have gone off and implemented this solution in almost to the letter, which is kinda scary. Kinda makes ya second guess online shopping.
BTW, I agree with you guys, store the cart in RDBMS
Really Great Article it is as i’m a beginner to web technologies,thanks a lot!
wow this is great !
go ahead thx.
<i>IMHO, sessions make sense. Memory and CPU power is realitively cheap. If you’ve got so much activity going on that you have to upgrade your server, it’s because you’ve got a lot of shopping going on which means income to offset the upgrades.</i>
Sessions are a bad idea here for as many reasons as other user’s have pointed out, but by the same token, if I have enough shopping going on to facilatate buying another server, then there is a good chance that I can afford to simply have a dedicated SQL box, which is much more reliable and is presistent.
This was an excellent article for the intended audience. I found this article on MSDN that, while more confusing, may add additional input.
Regarding the SQL vs. Session discussion, has anyone tried using XML to store such data. Just curious if the parsing overhead would be more costly than SQL and/or Session??
I would still lean to a database managed solution. It’s cleaner and more effecient in the long term.
Zak, could you or anybody else tell me how to Insert row from objDT ( your shopping cart DataTable) to a SQL server Table in a batch mode using a Stored Procedure. I am looking for an efficent method. Thank you.
Nice article however I think it misses a few points. Yes, building the basics of a shopping cart can be easy but the extras can be difficult and well worth the money to purchase. Integration with credit card gateways, real time shipping rates, administration forms and reports all take a lot of time to build and test. For some sites, yes, it might make sense to build a simple cart. For others you should examine your long term goals and do a build v. buy analysis.