DBContext is indeed generally not a good
solution (especially if you have more than one client that accesses to the
DB), so the refactoring you've started definitely makes sense.
Now you have a problem with lazy loading, because once you've reached
the end of the
using scope, you can't launch a SQL request
anymore as the context has closed its connection to the DB server
when it has been disposed.
The solution you're talking about
The other (very resource-hungry) method could be to store a
with each loaded object so that lazy loading still works...
is actually what's happening under the hood. Each loaded entity that
allows to lazy-load one of its navigation properties is related to Entity
Framework (that's those proxy-object of a type generated at
runtime that inherit from your POCOs), so it actually holds a reference to
Which means, if you don't dispose your
using), lazy-loading will still be available. This
wouldn't be the solution to all your problems though, because you probably
would have then to deal with multiple entities coming from
different contexts, and this simply won't work easily (for example
you can't add one entity coming from
DBContext instance A into
DBContext instance B).
Now, what's the solution then? Well, it probably will be
You currently have a 2-tiers application, i.e. your heavy WPF client
directly communicates with the database. Lazy-loading is enabled, which
means everywhere in your code (especially in the ViewModels), a SQL request
could be sent to the DB server. This is actually far from the unit of work
pattern that better works with a stateless 3-tier application. In such an
application, each time you call a service you have a new "unit of work" and
a new entity context instantiated.
If you were starting a new application, I would say: go for a 3-tier
stateless application, shorten the EF context lifetime as much as possible,
deactivate lazy-loading and work with detached entities everywhere in your
Now if you have already a lot of code, you probably have two options:
either refactor it all with those ideas about context lifetime in mind, or
make minor modifications to your current code to only fix the bugs you have
right now with your context-per-thread pattern.