views:

77

answers:

4

We are undergoing a migration from classic ASP with SQL and Sprocs. Our choice fell upon c#.net 4 Webforms with Entity Framework 4.

My question is how to handle the context. Example:

Calling repository function GetProductById(), which open up a new context (using) and then we change something on the object and we save it.

When we save it we wont be in the same context as when we fetched the object.

The above didn't really work for us. We then tried to send the context around in our application. While this worked we didn't really want to work this way if we didn't have to.

We are currently using a third option, storing the current context in a global variable. We dispose the context when we have saved it. However we're not sure if this is a viable way in the long run or if we're to hit a wall with this method.

We've tried to search for best practices on this topic but not really been able to find any. Would appreciate and help on this topic.

+2  A: 

The Unit of Work pattern described in this article might help, although the examples in the article are with an MVC app rather than an WebForms one.

http://msdn.microsoft.com/en-us/ff714955.aspx

Craig Vermeer
Thanks for a good reply. That is exactly the approach we've been taking, you helped us put a name on it.
Lars Thorén
+1  A: 

Use object keys

When you get an object from the DB and then manipulate it and after some time (after context has been discarded) want to save it back, use primary key values.

create a new instance of the correct entity object and set key properties (and those that have to be changes) and then save it against newly created context.

Or you can get it again before saving. It's a waste of resources but it is the most bullet proof way of doing it. Eve though I wouldn't recomend it.

Using ASP? Go with MVC then

I highly recomend you rather switch to Asp.net MVC if you're used to ASP, then you'll be better and easier at home in MVC.

Robert Koritnik
We've evaluated the MVC vs Webforms and for the kind of development our company is doing we feel that Webforms will suit us the best. However I don't really see how this affect my question as I assume the context would need to be handled the same way in MVC as Webforms?
Lars Thorén
@Lars: That's true. MVC doesn't really have anything to do with EF context. but since you've mentioned that you were developing ASP pages I thought I should advise you to go with MVC instead. If you don't have experience in WebForms you're probably into a world of unknown territory that will make your hair gray. At least much more gray as if you switch to MVC. Many developers that have the knowledge of both would probably say that switching from ASP to MVC is a much better option than WebForms. If you were a Win desktop app developer, then WebForms would be your best option.
Robert Koritnik
+1  A: 

Another option available to you is to have the context be put on the thread request. This is done by creating the context on the BeginRequest event of a HTTPModule. You then need to be sure you handle any resources you have created that need to be disposed of in the EndRequest event.

John Ptacek
A: 

After getting a label on our way to work (Unity of work pattern) we found this link that is pretty much exactly how we work and it might be helpful for anyone with the same thoughts as we had:

http://dotnet.dzone.com/news/using-unit-work-pattern-entity?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fdotnet+%28.NET+Zone%29

Lars Thorén