Entity Framework DbContext Wrapper

Keywords: DbContext, EntityFramework, DbWrapper, DbContext Wrapper, Repository over Entity Framework, C#
Publish Date: 1/3/2016
Description: A class to wrap the usage and lifecycle of Entity Framework DbContext

Problem Scope:

In many Enterprise implementations of Data Access using Entity Framework, the DbContext is not allowed to roam free in every layer. Some minor effort is needed to initialize and call the DbContext inside a using statement to ensure the context is disposed.


This class leverages Func<> and Action<> called inside a using statement in order to control the management of the DbContext. It is mockable (NSubstitutable lol) because it implements an interface and you can replace any methods in a sub class. EF Proxies, Change Tracking, and Lazy Loading don't work properly after the context is disposed, and since this particular solution is geared toward a short lived transactional EF pattern, we disable them.

Notes on Repository over Entity Framework:

This might be suitable for a lighter weight replacement for repository over EF, which I have implemented at least a couple times then moved away from it. Here are some Blog warnings about Repo over EF.






Another important consideration is that the version of generic repository over EF that is getting the backlash might be the inheritance version. The one that has a base repository of <TDbSet<TEntity>> that forces structure on it's sub repositories. This wrapper could still fit in a repository pattern as an injected property without any opinion on how to use the DbContext, just that it should be inside a using statement.

Example Project (vs2015): DbContextWrapperExample.zip

Example usage:

Comments (2):

Name: Mario Hines
Comment Date: 2/8/2016
This isn't that bad. Conceptually speaking...it's much lighter weight than a repository pattern. However...the problem that I see here is that the context is exposed and the developer loses single responsibility. While practical for a good UoW pattern...the wrapper can assume far too many responsibilities (line 49 and 51 are working with 2 different tables). Although in the long run, this may not be a problem for the developer.

Name: Allan Chadwick
Comment Date: 2/9/2016
Mario! I like debating with you. You always make excellent points! Ok... Are you saying that DbSet would be better to expose than DbContext? If so I think DbSet single responsibility can be destroyed quite easily (and often does in the wild) with the includes method. If you are saying that my example code is the problem, very true. It's a bad example, but the wrapper class doesn't have to be injected straight into a console app or boundary class like a controller. More classes that decrease the scope of responsibility can and should be exposed to represent some logical data access instead of just this, but at a bare minimum something should exist to enforce the smallest life cycle for the context. That is pretty much the offering of this class, just a helper to reduce scope of the DbContext. Hey, if you want to post some code, I'll give you a login, or include it on this post. Thx!

Leave a Comment:

    Captcha Challenge