I have several classes based on System.Entity.Data.DbContext. They get used several times a request in disparate ends of the web application – is it expensive to instantiate them?
I was caching a copy of them in HttpContext.Current.Items because it didn’t feel right to have several copies of them per request, but I have now found out that it doesn’t get automatically disposed from the HttpContext at the end of the request. Before I set out writing the code to dispose it (in Application_EndRequest), I thought I’d readdress the situation as there really is no point caching them if I should just instantiate them where I need them and dispose them there and then.
Questions similar to this have been asked around the internet, but I can’t seem to find one that answers my question exactly. Sorry if I’m repeating someone though.
Update
I’ve found out that disposing of the contexts probably doesn’t matter in this blog post, but I’m still interested to hear whether they are expensive to instantiate in the first place. Basically, is there lots of EF magic going on there behind the scenes that I want to avoid doing too often?
I’m answering my own question for completeness.
This answer provides more information about this issue.
In summary, it isn’t that expensive to instantiate the DbContext, so don’t worry.
Furthermore, you don’t really need to worry about disposing the data contexts either. You might notice ScottGu doesn’t in his samples (he usually has the context as a private field on the controller). This answer has some good information from the Linq to SQL team about disposing data contexts, and this blog post also expands on the subject.