8

We have a static class library to deal with repeated multi-contextual tasks. Is it bad practice to create an EF db context as member of a static class?

DB contexts are meant to be disposed of for a reason. Having them disposed frequently keeps the connection pool "flowing" and probably (here I'm speculating) assures that tables don't remain locked.

So am I inviting trouble having a db context in a static class or am I overthinking this?

Dave Alperovich
  • 32,320
  • 8
  • 79
  • 101

2 Answers2

14

IMO this is definitally not something you want to be doing.

Locking isn't actually the main problem you are going to have here. EF will only lock for the duration of a save changes call (its actually one of the big benefits of using a tracking graph over partially committed transactions which most other ORMs use).

What is going to cause you greif is the tracking graph itself. How EF works (in most cases) is that it keeps a copy of every entity its ever seen and loops through them to find whats changed and run a process called fixups which makes navigation properties work with backlinks. This process loops through every entity the context has ever seen and is called on a bunch of operations (add, attach, delete, save, query and a few others). This means if the tracking graph is large, this process can take quite a bit of time. If you keep your context alive forever the tracking graph size tends toward the size of your database, making it unwieldy and slow.

undefined
  • 33,537
  • 22
  • 129
  • 198
  • Thanks for the confirmation. I agree. – Dave Alperovich Jan 25 '13 at 17:05
  • 2
    @davea On a bit of a sidenote I use dependency injection to manage context lifecycle, with either a new instance per request (in a web based scenario) or a new instance every time. – undefined Jan 25 '13 at 17:10
  • Luke, I've read about DI as a pattern and understand some of its value. Would using a framework like Ninject help me here? – Dave Alperovich Jan 25 '13 at 17:11
  • @davea I use ninject in all of my web projects (and some other types of projects too) and find it really useful. The problem that it solves is object lifecycle, ie when/how to construct objects and when to dispose them. In my opinion its most useful for the consumers of Contexts but I still use it to manage to context lifecycle as well. Personally I recommend it, If you want to see an example of how I use ninject and EF check out the code on my generic repository post: http://blog.staticvoid.co.nz/2011/10/13/staticvoid_repository_pattern-nuget the example solution at the bottom is useful. – undefined Jan 25 '13 at 17:29
  • Thanks Luke! I will definitely read up on it. If you have time I suggest you revise your answer to include Ninject. Thanks again. – Dave Alperovich Jan 25 '13 at 17:37
6

It depends on many things, but here are some thoughts e.g.:

  • If you're using EF on service layer - then the concurrency might be an issue as I don't think that using EF context is thread safe, ie that you can use it from all threads at the same time without problems
  • If you have your entities tracked by the context (and I think even if you don't), the context would in time get quite large, eventually it could contain all of your database entities and then you'll run into performance problems

Either way, I think it's a bad idea.

veljkoz
  • 8,384
  • 8
  • 55
  • 91