Clever Geek Handbook

ASP.NET MVC Entity Framework ObjectContext

  • We went back and forth about how we want to manage our ObjectContext for our enterprise MVC solution. We are looking for the pros and cons of keeping the ObjectContext between requests without having to create one for each request.

  • Let's say we have a product controller redirected from \ site \ product \ edit \ 34. The edit action calls our repository (which currently has an object context in the ala NerdDinner repository ). Then it goes to the view and the user makes some changes and hits "Update". Then it goes back to the edit action of the product controller (message this time). The model binder returns the product to me (as updated). My question is, should I create a new object context with this new "update" request, or should I store the context (say in context elements) and call it from some id that I have stored in the page?

+2


source to share


1 answer


First, your web application should be stateless whenever possible. You don't want to inject code into your application that relies on the web server that served the page for the user to be the web server that handles the actual update. You may not intend to deploy a server farm right off the bat, but if you ever make the transition, you won't need to rewrite your application to do so. That in itself is a good reason not to try to store the object somewhere, and I didn't even mention Entity Framework or MVC specifically.



As it turns out, ObjectContext is actually pretty lightweight. If you are doing your generation of compile-time views (Google it), the cost of one has very little overhead.

+3


source






More articles:


All Articles