Correct usage of EF's DBContext in ASP.NET MVC application with Castle Windsor
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).