ASP.NET MVC Entity Framework ObjectContext

Question

1. We've been going back and forth on how we want to manage our ObjectContext for our MVC enterprise solution. We're looking for the pros and cons of storing your ObjectContext between requests opposed to creating one on each request.

2. Let's say we have product controller routed to from \site\product\edit\34. The edit action calls our repository (which currently has the object context in the repository ala NerdDinner). It then goes to the view and the user makes some changes and hits "Update". That then comes back to the product controller edit action (post this time). The model binder will bring me back the product (as updated). My question is, should I be creating a new object context with this new "update" request or should I have stored the context (say in the context items) and called to it from some id that I saved on the page?

Answer 1

First, your web application should be stateless, whenever possible. You don't want to code into your application a dependency that the web server which served the page to the user must be the web server which handles the actual update. You may not intend to deploy to a server farm right off the bat, but if you ever make that jump, you will not want to have to rewrite your application to do it. That alone is a good reason to not try and store the object somewhere, and I haven't even mentioned the Entity Framework or MVC specifically.

As it turns out, though, an ObjectContext is, in fact, fairly lightweight. If you do your view generation at compile time (Google it), spending one up has very little overhead at all.