In Entity Framework, the DBContext class is said to implement the unit-of-work pattern. As I interpret this, it means that if you make a DBContext, manipulate its data, and then dispose of it, then these manipulations will either all succeed together or all fail together, and get rolled back. Moreover, there is the potential for a performance benefit, as the underlying infrastructure gets to see everything you're doing at once, and do things like combine operations. This instantiate/manipulate/dispose sequence would typically comprise a using block in most C# code.

This all seems eminently logical, but when I try to read about DBContext as it performs in an ASP.NET MVC application, I run into statements I just don't quite get, e.g.:

"DBContext relies on several managed features and flags that keep track of changes in items that have been queried from the datastore... [t]he stateless nature of ASP.NET MVC prevents the default functionality of Entity Framework from working, however."

(Developing ASP.NET MVC 4 Web Applications, Exam Reference 70-486 by William Penberthy, Microsoft, 2013, p. 5)

I'd really like some more specifics about this supposed breakdown in the "default functionality of Entity Framework". Am I to understand that if I build a using block around a DBContext and some manipulations thereon, say, in a controller method, then a trip through this using block no longer comprises a single unit-of-work? Can I no longer expect each set of manipulations to either get committed as a whole unit or rolled back as a whole unit under ASP.NET MVC?

Or, alternately, does the breakdown in the "default functionality of Entity Framework" relate solely to the performance benefits obtainable from the use of a DBContext? I guess one possible interpretation of the statement I'm asking about is just that multiple, concurrent requests (e.g. to my example controller method) won't have their database manipulations combined for increased performance.

For example, if 999 people update a single column of the same row in a database, in quick succession, then all of these updates will end up happening individually... which is something I wouldn't have thought required mentioning. It certainly doesn't mean that using blocks build around a DBContext work any differently in ASP.NET MVC.

In any case, if you understand the statement I quoted better than I do, then I would appreciate your help in understanding it.

1 Answer 1


The problem amounts to maintaining server state in an application environment that is stateless by design.

Consider what happens when you implement a shopping cart. Shopping carts involve several steps: you must choose the items you want (usually one at a time while looking at product pages), put in your address, select the shipping type, supply a method of payment, and finalize the order.

Each page that you submit to the server during this process is essentially a complete transaction. REST architecture assumes that, once the request/response cycle is complete, there's nothing left to do.

To track progress on a shopping cart using a DBContext, one would have to open a DBContext, say, whenever the user puts their first item into the shopping cart. The problem is, where do you hold this object open? DBContexts are normally closed when the page is submitted. What happens if several users open shopping carts? Now I have to keep track of all those DBContexts. What happens if someone abandons a shopping cart?

What we're really talking about are SESSIONS. Martin Fowler talks extensively about SESSION state in his P of EAA book, including whether to store SESSION state on the server or the client, and the advantages and disadvantages of each approach.

  • Thanks... so are you saying that ideally one would use a single DBContext instance from the initial creation of the session shopping cart through check-out (or abandonment of the cart)? If that's what you mean, then I can certainly see where an ASP.NET MVC application might not lend itself to that. Commented Jan 24, 2015 at 21:12
  • 1
    I am saying that session state would be handled some other way than holding a DBContext open. The SESSION state might be persisted to the database between pages, for example. Or, it can be held in a browser cookie or hidden page element. Commented Jan 24, 2015 at 21:35
  • OK, I get it. It just seems strange (to me) to say that the request/response model "prevents the default functionality of Entity Framework from working". I would have just said something like "you can't leave DBContexts open for subsequent requests in the same session, and that presents some architectural issues". Commented Jan 24, 2015 at 21:39
  • 1
    You can, but then you'd have to store it as a member variable of the repository or service layer. You'd have service layer methods representing incomplete transactions (not units of work), and that wouldn't be good either. Commented Jan 24, 2015 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.