Correct usage of EF's DBContext in ASP.NET MVC application with Castle Windsor 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&lt;Entity&gt; Entities{ get; set; }
}


Register DBContext with my implementation:

public class PersistenceInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(Component.For&lt;DbContext&gt;()
                                    .ImplementedBy&lt;MyContext&gt;()
                                    .LifestylePerWebRequest()
                          );
    }
}


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.
        };

        db.Set&lt;Entity&gt;().Add(entity);
        db.SaveChanges();

        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.
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&lt;T&gt;'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).