Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Porting the MVC Music Store to RavenShoppingCartController

time to read 3 min | 600 words

The ShoppingCartController is heavily affected by the changes we made to the ShoppingCart. Let us look at those changes, starting from Index():

image image

On the left, we have the original version. You can see that it executes two different queries to process this order, the Raven version, however, is executing only a single query, in the FindShoppingCart method:


This just implements the logic of loading the cart from Raven or creating a new cart (with the specified shopping cart id), note that we don’t save the new cart to the database here, merely associate the new cart with the session. There is no need to save, since it contains no meaningful data at this point. When we will call SaveChanges(), the new cart will be send to Raven for storage.

Let us look at the AddToCart action now:

image  image

On the left, you can see the old version, and on the right, you see the Raven version. They are pretty similar, except that in the Raven case, the shopping cart’s AddToCart is concerned solely with adding a new item to the cart or incrementing the quantity of an existing item. There is absolutely no data access in the Raven’s version of ShoppingCart.AddToCart.

One major difference is that the Raven approach is calling the session.SaveChanges() in the action code. The reason for that is simple, it is the proper place for this, as the calling code, it is responsible for the environment, including saving when needed.

image image

Raven’s code is pretty easy to follow here, I think. There is just one thing that you should note, the last line is pretty strange id.Split ? Why do we do that?

The reason for that is that Raven uses id that looks like this: “albums/616” and the DeleteId is used by the calling javascript code to find an element by its id. An element can’t contain a ‘/’ in it, so we strip it away and only send the number part of the id. This is safe to do since we only deal with albums here.

image image

Again, this is about as simple as you can make it, so I’ll note only that Raven’s approach can benefit from the unit of work cache, and the old code approach can’t.

In my next post, we will deal with the order process.

More posts in "Porting the MVC Music Store to Raven" series:

  1. (27 May 2010) ShoppingCartController
  2. (26 May 2010) ShoppingCart


David Thibault

I believe that shoppingCart.Lines.Count should be shoppingCart.Lines.Sum(x => x.Quantity)

However I did not look at the original code so it may be correct.

Jason Meckley

an approach I use with controller's is post-redirect-get for commands. by managing transactions (SaveChanges) from a Filter there is no need to call session.SaveChanges() in the action. you also avoid the "resend post data" if the user refreshes the page.

in this series you are only porting the data access, so keeping the controllers as similar as possible makes sense.

What are your thoughts?


@David Depends on what you are intending to show. The line count or the total item count.

Michael Teper

Wouldn't session.Load <album(id) call be data access?

Michael Teper

Ugn, subtext ate the generic part. Here's what I meant:

Wouldn't session.Load(id) call be data access?


@Michael, I believe he's means the ShoppingCart model does not include any data access code.

See his previous post: "Porting the MVC Music Store to Raven: ShoppingCart" (sorry, edited due to link being consider spam.. ugh!)

The calling code, in this case the controller, is responsible for loading and persisting the model.

I suppose you could add another level of abstraction by introducing a ShoppingCartService that managed the data access instead of the controller, but for a simple application, this is probably overkill.

Ayende Rahien


Post/redirect/get is much better option, sure.

Ayende Rahien


Sure it is, but it is not in the shopping cart code


Oops... sorry for the double post. I didn't expect Ayende to moderate my comment so quickly. Thanks!

Michael Teper

Ayende, Kiliman, you are both right, I missed the ShoppingCart reference. Thanks!

Harry Steinhilber


The point was that ShoppingCart.AddToCart() does not contain any data access. The data access is in the ShoppingCartController.AddToCart(). In the original version, the data access was in the business object instead of the controller.


For the DeleteId value, HTML id can't start with a number ( http://validator.w3.org/docs/errors.html#ve-122). So instead of returning the number part of the id, you should return the full id minus the "/" : DeleteId = id.Replace('/', string.Empty)

Michael Valenty

Why would you prefer cart.Lines.Count over cart.GetCount()? cart.Lines.Count is a Law of Demeter violation. You don't encapsulate the logic that @David pointed out should actually be cart.Sum(x => x.Quantity). Maybe it should be a property to suggest it's not an expensive operation, but it seems like it's something the cart should own.

Ayende Rahien

cart.GetCount() was a database query, very expensive.

I don't care about the actual impl detail, I care about whatever this is an in memory operation or a remote operation

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats