Persisting Carts

While you have the overhead of a database call to persist any changes to your cart (you can use an isDirty to decide whether to reload the cart if performance becomes a concern), I like persisting carts as an order where status = 0 (not yet placed).

Firstly I don't need to create a whole other session or cookie based persistence mechanism. I can just load a simple session based bean using base classes. Secondly I can associate carts to users, allowing people to add something to their cart at work and then to access the cart from home by logging back in. Thirdly, carts don't time out after 20 minutes of so of inactivity (session timeout). Fourthly it allows me to run much richer reporting as I can run all of my commerce reporting against incomplete carts as well as against completed orders (they're in the same table). Would it be interesting to see the "most abandoned products" or "total sales abandoned this month"?! Just change the order status filter in the query and existing commerce reporting can provide these kinds of stats. You can also use the same mechanism to handle wish lists or other persistent picked product lists. Of course, you have to have some kind of scheduled task to clear up abandoned carts after a period of time, but I find that a small price to pay for the benefits. (I'm not sure how well this would work on a really high traffic site, but most of my customers are happy to have tens of orders a day, so it hasn't been a problem).

You also have to be a little clever about your cart association rules. I typically run clients through the various cart persistence issues. For example, if an anonymous user logs in and adds an item to their cart, what happens when they log in if they previously had a cart with two other items in? The options are to just wipe the old cart, to auto add the two old items to the cart or to ask the user. I tend to recommend wiping the old cart as users don't usually want items just jumping into their cart and they will probably be confused if they're asked about old items they may well have forgotten. Most of the time this is not an issue as I typically use cookies to pre-identify users returning on an existing machine and if a user logs in before adding something to their cart I associate them to any existing cart, but it is something to think through if you implement a similar approach.

There are also privacy issues with the cookie and stored cart – especially on shared computers (look what little Jimmy put in his shopping cart), so I typically recommend making the cart associations a user option ("remember me on this computer") and provide the option of disabling the entire feature for stores that don't want or need the feature.

Cart Methods
The methods required by the cart controller depend on the functionality of your cart. I'm going to ignore online gift certificates for now which leaves my use case with a simple cart controller with the following required methods:

• addtoCart()
• updateCart()
• deletefromCart()
• setDiscountCode()
• setShippingZIP()
• setShippingMethod()
• viewCart()

Following best practices, I require a POST method for anything that changes state (the first six methods) – I'd hate for the Google Web Accelerator to go round adding products to my cart by prefetching a bunch of "add to cart" GET links! I also tend to support adding n-items to a cart per click (if you're adding from a product list or a quick add screen), and use a generalized n-attribute comparison so the determination of whether to add a new item or to increase the quantity of an item is driven by the ID and by whether the trimmed attribute values selected/defaulted are identical or not (if I add a green sweater monogrammed "ab", I don't want that to increment the quantity of the green sweater monogrammed "cf", but if I just add a green sweater and then another identical one, I don't want two separate rows in my cart!).

As for the object model, I'll go into that a little more after the checkout as most of the drivers for order and order item attributes come from the checkout functionality required (from discounting rules to shipping calculations).