Ok, so finally I have an e-commerce related post.  Tonight I was adding cross-sells to my site.  The concept is simple - when displaying a product, at the bottom of the product page, list products that might also be of interest to the shopper.  To facilitate this, you'll need a Cross Sell table:

This table just contains two product id's.  One is the product Id of the item the shopper is currently viewing, the other is the product Id of the product that you want to cross sell.  So all you have to do is make a call out to your database by passing your product Id and return one or more products that you want to cross sell.  Then display them.

In the past, I would have written a stored procedure to retrieve the data.  Something like this: 

But I'm moving away from stored procs in this new e-commerce site I'm working on, and using Linq to Sql.  I have written hundreds on basic linq queries, but how do you accomplish this task?  I have a select embedded inside a select.  Well, here is the solution:

First grab your Cross Sell records and store them in a var called crossSells.  Then create another query from your Products table, join to manufacturers (to get the manuf. name for dispay purposes), and set the where to get those items from crossSells that contain your productId.  No matter how many "queries" you construct, only one SQL statement is executed.   Your var is an IQueryable and you can embed these inside others.  Very cool and very easy to get straight in your head when you seperate them. 

Your SQL query isn't actually constructed and run until you enumerate over it (call .ToList() for example).  In the above code, I want to return a generic list of Product objects. So, after creating my two linq statements, I return products.ToList();

The SQL that is created can be easily seen.  Just set a breakpoint on the return statement and look products. 

There you have it.  Move away from stored procedures and into the cool world on Linq to SQL (or Linq to Entities).

Thanks to Rob Conery's blog for this information.

great post by Dan Wahlin here on the pros and cons of SL3 developement.  I have been wanting to blog more on my experiences in e-commerce development but am struggling to find time.  I'm a one man shop at the moment!  Work on my new ASP.NET site is coming along nicely.  I have a professional UI in place now, just tidying up the paging and completing the checkout process.  Once that is finished, It's back to my SL3 administration application.  Silverlight is such a great platform and it's really going to allow my customers to efficiently manage their store. 

More blogging to come...

In my previous e-commerce travels, I've taken the easy way out.  Not this time.  Need to do better.

Say Mary comes to my site and adds two red balls, and a silver whistle to her cart.  She signs in to her account and starts the checkout process, but then her 2 year old starts screaming bloody murder.  She shuts down and vows to come back later.  Well later turns out to be 2 weeks.  When she comes back to my site, she remembers what she wanted - two red balls and a silver whistle.  So, she adds those to her cart and also finds a really nice erector set for her son.  She clicks checkout, which redirects her to log in.  Upon logging in, things can get interesting....

Her "registered" account already had two red balls and a silver whistle from 2 weeks ago.  So here are the options:

1) wipe out whatever was in her "registered" cart and migrate over her items that she just added when she was an anonymous shopper.

or 

2) merge everything together, taking special care to add in the matched items as well as the unmatched items.

The easy way (from a programmers perspective) is to dump the "registered" accounts cart and just add in the items when she was just an anonymous shopper.  No need to mix and match, just dump, add, and move right along.  This would work great in this case, because Mary remembered what she wanted and re-added those items.

If I were to play the mix and match game, she'd end up with 4 red balls, 2 silver whistles, and a cool erector set in her cart.  If she doesn't pay attention to the quantity textbox, she might overbuy on red balls and whistles and trigger a refund.  Of course I'd like to think that everybody pays attention to what's going on in their shopping cart, but things slip though unseen.   Happens to us all.

Now, I'm not a lazy programmer.  I strive to give the best shopping experience possible.  So I've got to do better.  I could merge all the items together and throw up a message telling the shopper that some quantities have changed.   Another idea is to only keep what the shopper has added to his/her cart during this session and *if* they just so happen to click on the shopping cart image/link, then throw up a "hey you have items from a previous visit, would you like to keep them? "   I kind of like that idea, I can ask before doing an auto-merge.  That's simple enough.  But I have to give the shopper a great UX to go with my great prices so they keep coming back.

Of course, this is just one scenerio.   If you store cookies on the users machine, you could find the cookie and then hit the shopping cart table and automatically bring in any existing items.   I'm sure there are lots more crazy things people do and have done to them (think crashes).   So this is what I'm trying to think about today.  I think I'll jump on some sites today and see if I can find something cool I have not thought of.  After all, I know my competition does this to me :)

Any great ideas out there?