Suggestions on storing shopping cart info

[Cirene]

I am writing a shopping cart app in asp.net.

So far I created 2 classes, 1 for customer_info (name, address, email), 1
for product_info (prodname, price, description).

As the shopper adds things to the cart and navigates throught the site to
shop more, should I store this info in a session var? What is the typical
way? Should I create another class for cart and store an array of
product_info to keep track of what's in the cart, etc...?

What do you recommend?

Thanks

 

[Cirene]

Thanks Mark, as usual. I'll give it a try...

That would work. Alternatively, if you want the customer to be able to
save the cart and come back to it later, you should save it to a
database...


That's what I do, though I tend to use a generic e.g. Dictionary<int, int>
to store the ID of the purchased product along with the number of items
purchased...

 

[Cirene]

Would using a generic list (of these objects) be the best way to handle this
in your opinion? Store that to a session var?

 

[Cirene]

But to perisist it using a session var doesn't using a List allow you to
easily access, add and remove items in the cart? Or should I just use an
arraylist of the cart items?

I was just looking at this and it seemed like a good idea...
http://www.java2s.com/Code/VB/Generics/GenericListstoresGenericClass.htm

By the way i'm not sure what "top-posting" is. I just hit "Reply to Group"
in Outlook Express.

[please don't top-post]

Would using a generic list (of these objects) be the best way to handle
this in your opinion? Store that to a session variable?

No it wouldn't, otherwise that's what I'd be doing. I've never found any
need to persist anything other than the ID of the item bought together
with the number of items purchased.

 

[George]

[please don't top-post]

Would using a generic list (of these objects) be the best way to handle
this in your opinion? Store that to a session variable?

No it wouldn't, otherwise that's what I'd be doing. I've never found any
need to persist anything other than the ID of the item bought together
with the number of items purchased.

I would disagree... (as a guy who has some experience in a-commerce, my site
www.mspiercing.com )
Here are some thoughts (from 3 years experience of having web site).

1. Items might have options ( and sometimes more than one option). Id of
the item will be the same but color different.
So if you want to keep them in memory then create clsItem object which goes
into shopping cart (generic list is perfect). So it will have ItemId,
Options selected, Quantity, Price and who knows what else...

2. Why to have a price... In real word you will change a price... and you do
not want to get a mad customer who added "green tv" to the shopping cart for
5.95 and suddenly when he checked out that "green tv" became 10.45. Simply
because you and people who work in the E-commerce store work during the day
and changing prices right in a middle of the day when people are shopping..
Keep that in mind.

3. It's generally bad idea to keep shopping cart in memory. Simply because
you want to see how many attempts were made to buy staff from you.. Believe
it or not but 50% people do not complete purchase. They add staff to
shopping cart but never proceed all the way to complete the order. And you
want to see what people were looking at... So keep it in DB so you could
look/analyze at it later... Or help out some customer who calls you and says
that he wanted to buy "green tv" from you and added it to the shopping cart
but his computer/internet died and he can not complete the order.

4. Order table must have all information about items (price, name, ...)....
So it becomes frozen in time. Person might want to look at his previous
order (especially if its business customer and he needs to print out invoice
for IRS) and he needs to se price he ordered this item for 6 month ago and
not new price... Or if item was discontinued and removed from inventory...
Still you need to show complete info... like name, picture....


George.

 

[Cirene]

Many great suggestions and good points! Thanks! Let me mull it over and
see if I have anything else to ask...

[please don't top-post]

That's what I do, though I tend to use a generic e.g. Dictionary<int,
int> to store the ID of the purchased product along with the number of
items purchased...

Would using a generic list (of these objects) be the best way to handle
this in your opinion? Store that to a session variable?

No it wouldn't, otherwise that's what I'd be doing. I've never found any
need to persist anything other than the ID of the item bought together
with the number of items purchased.

I would disagree... (as a guy who has some experience in a-commerce, my
site www.mspiercing.com )
Here are some thoughts (from 3 years experience of having web site).

1. Items might have options ( and sometimes more than one option). Id of
the item will be the same but color different.
So if you want to keep them in memory then create clsItem object which
goes into shopping cart (generic list is perfect). So it will have
ItemId, Options selected, Quantity, Price and who knows what else...

2. Why to have a price... In real word you will change a price... and you
do not want to get a mad customer who added "green tv" to the shopping
cart for 5.95 and suddenly when he checked out that "green tv" became
10.45. Simply because you and people who work in the E-commerce store work
during the day and changing prices right in a middle of the day when
people are shopping.. Keep that in mind.

3. It's generally bad idea to keep shopping cart in memory. Simply because
you want to see how many attempts were made to buy staff from you..
Believe it or not but 50% people do not complete purchase. They add staff
to shopping cart but never proceed all the way to complete the order. And
you want to see what people were looking at... So keep it in DB so you
could look/analyze at it later... Or help out some customer who calls you
and says that he wanted to buy "green tv" from you and added it to the
shopping cart but his computer/internet died and he can not complete the
order.

4. Order table must have all information about items (price, name,
...).... So it becomes frozen in time. Person might want to look at his
previous order (especially if its business customer and he needs to print
out invoice for IRS) and he needs to se price he ordered this item for 6
month ago and not new price... Or if item was discontinued and removed
from inventory... Still you need to show complete info... like name,
picture....


George.

 

[Cirene]

Thanks as usual...

[top-posting corrected]

But to perisist it using a session variable doesn't using a List allow
you to easily access, add and remove items in the cart?

It may do, but it's completely unnecessary IMO and just takes up more
memory on your web server.

Say you have a widget with a product ID of 24, and someone buys two of
them - what else do you need to persist other than {24, 2}...? Now, say
they return to the cart and buy an extra widget - all your code has to do
is to change {24, 2} to {24, 3} - could hardly be simpler...

Or should I just use an arraylist of the cart items?

Use an arraylist if you absolutely have to - I prefer to use a

By the way i'm not sure what "top-posting" is.

It's when people post their replies *above* the text that they're replying
to, which is completely opposite to the way that conversations work. When
you read an article in a newspaper, you don't read from the bottom-up...
Top-posting means that people are forced to read the conversation
backwards, e.g.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in newsgroups?

I just hit "Reply to Group" in Outlook Express.

Er, yes, so just move your cursor *below* the text that you're replying
to - it's really quite simple...