I’m building an ASP.Net website. I have a “cart” class which stores the items in the users cart. I don’t want to re query the database every time the page reloads to populate the cart items stored in this object. Is the best way to store/persist instantiated objects by putting them in a session and store the session to a database (we’re on SQL Server 2k8)? It seems like that’s what most are recommending from reading other posts on StackOverflow. Our site has a pretty high amount of traffic, so its easy to imagine 1000’s of these objects being active at any given time.
I’m new to building ASP.Net websites. Is it common practice to persist user objects (not just simple variables in a session or cookie, but class objects)… also along the lines of persistent objects, I plan on creating a static class which stores commonly used site-wide data such as a List of U.S. states… are there any pitfalls with doing this? I don’t want to shoot myself in the foot.
Update:
We are in a farm environment so storing sessions in a daatabase seems out of the question… if one server goes down we roll over to another… in which case the session data may be lost. We were considering using a separate server for storing sessions, which would work in our farm environment but I’m iffy about storing that many instantiated objects in memory.
Session is likely your best option.
Since you are using SQL as your Session holder it will be out of process, so you will have it available on a web farm without issue. Though, you will still be having a database hit every time you reference that object. However, it is a highly efficient database hit.
Just be sure to make sure your Cart class is ‘serializable’ otherwise it will blow up going to Session.