Database – HTTP Session or Database approach

databasedesignsessionweb-applications

I am confused a little as what should be my approach, Working on a design of shopping cart and i need to store shopping cart either in session or in database but not sure which approach would be best.here are the use case

User is not logged in and adding product to cart (Anonymous user)
User is logged in and adding product to cart.

First case is more confusing to me, since there can be many cases where user just visiting web-shop and adding product without logging in and can be quite possible that he might not going for a checkout process.

But still we need to create a Shopping-Cart for this user, in order to create and save shopping-cart i have two option.

When user adding a product, create a cart in the database and associate this cart with this user, moment he logged in move this cart to logged in user.
Create Cart, add product to it and save it to the Session, when user logged in create Cart in the database and associated logged in user with this cart with User.

I know that both database driven Cart system as well Session based can have there positive as well negative aspects, but not sure which one might be the best approach taking in to account following points

Scalability
Flexibility
Extensibility
Application Should take care of speed

Looking for input on this aspect to decide the path.

Best Answer

I would go for a solution where an unique ID is assigned to all visitors when they first hit the site. It doesn't matter if they're anonymous or authenticated. When anonymous users register, retain the unique ID.

Store the shopping cart in the database. Storage is cheap, and it shouldn't be a problem performance-wise to do a query for the cart every now and then.

Related Solutions

Web-development – User session timeout handling in SaaS apps – discussing several approaches

I think the most common simple solution is where you set a timer on the client end that shows a message after a certain portion of the normal timeout window has passed then forcibly logs them out right before the session would expire anyway if they take no action.

Local storage and auto-save introduce some issues with transactions and what saved really means. I have been on quite a few projects where this has turned out to be more trouble than it is worth when the user base does not understand the mechanics behind it.

Never logging out can be done where regulations permit, but it leads you into mistakes where you do not correctly handle what happens if someone is logged out unexpectedly, and all the state business becomes a little intensive to maintain if there is very much to track on an "active" user.

Java – Designing application flow

When I look at your use case, I start thinking about separation of concerns.

The controller shouldn't care if the cart is in the request or not.
The service call that adds Items to a cart shouldn't care if the user is logged in or not.

I then think:

Request objects are a pain in the butt to test with
A Facade feels kind of vague for specific use cases. What if we could create a simple Data Transfer Object for each use case that has the data needed?

So I would start with something like:

Controller

Status addItemToCart(HttpServletRequest request, Item item) {
  if(request.getSession(false) == null) return needLogin(request)

  UserCart cart = service.addItemToCart(item, new UserCart(session))
  return cart.saveToSession(session)
}

Service

UserCart addItemToCart(Item item, UserCart userCart) {
  if userCart.needsCart() {
     userCart = cartDAO.getNewCart(userCart)
  }
  userCart.addItem(Item)
  return cartDAO.updateCart(userCart)
}

My Service layer tests would insist on something like UserCart to keep me from having to mock HTTPServletRequests and create 10 lines of setup code. UserCart is just a dumb Data Transfer Object with some convenience methods, but it makes everything much simpler to understand. User has-a shopping cart is important to this use case, so it's where my brain goes pretty quickly. This also allows us to avoid all the null checks and nested blocks that become rampant when you go out of your way to avoid creating simple domain specific concepts.

Related Topic