Take the 2-minute tour ×
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.

I am trying to use Entity Framework as simple as posible. Use UnitOfWork and Repository patterns seems to be overkill because whole web application will be pretty straightforward. I came with this idea:

public class Entity

public class MyContext : DbContext
    //Set database connection details here.

    public DbSet<Entity> Entities{ get; set; }

Register DBContext with my implementation:

public class PersistenceInstaller : IWindsorInstaller
    public void Install(IWindsorContainer container, IConfigurationStore store)

And finally I am using DBContext in controller this way:

public class HomeController : Controller
    private DbContext db;

    public HomeController(DbContext db)
        this.db = db;

    public ActionResult Index()
        var entity = new Entity
            //Set properties here.


        return View();

Is this correct approach? Could there be any memory leaks or potential DBContext lifetime management problems? Could there be any problem with too many database connections opened?

I would say that this could be correct. From my quick testing it looks like it is working even when I need to use DBContext in component which is then used in controller. So DBContext instance will be shared for everything per one request. Which is the way how it should be used, I guess.

share|improve this question
IMO you should'nt depend on DbContext. DbContext is plumbing to supply your own MyContext with underlying functionality. It's not an interface to use throughout your code. –  rmac Jan 7 '13 at 12:11

1 Answer 1

up vote 11 down vote accepted

You're doing it right - per-request lifestyle is exactly what you need, and you got it; this ensures your favorite IoC container disposes your context at the end of each request, and serves a new instance at each new one.

One thing bothers me though, and it's not about your code:

Use UnitOfWork and Repository patterns seems to be overkill because whole web application will be pretty straightforward.

You're using Entity Framework. DbContext, with its DbSet<T>'s, is a unit-of-work/repository pattern implementation. Some will argue it's done wrong and it's their right to be religious about a design pattern. The point is that if you use it correctly, a DbContext is a perfectly acceptable unit of work, especially if you're looking to get the damn thing done and in-line with KISS. Just make sure you call SaveChanges() as little as possible - once per request, i.e. once per instance.

If you're worried about db connections, open up your favorite SQL profiler against your database server instance, and see for yourself!

Bottomline, a DbContext is an abstraction layer over lots, lots of plumbing already. Abstracting it is often over-the-top, unless you wish to decouple your data layer from the rest of your app (say, swap EF for NHibernate).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.