EF and repository pattern - ending up with multiple DbContexts in one controller - any issues (performance, data integrity)?

Question

Most of my knowledge of ASP.NET MVC 3 comes from reading through the book Pro ASP.NET MVC 3 Framework by Adam Freeman and Steven Senderson. For my test application I have tr

Answer 1

As promised I post my solution.

I came across your question because I was having trouble with the IIS application pool memory growing beyond limits and having multiple DBContexts was one of my suspects. In retrospect it is fair to say that there were other causes for my trouble. However, it challenged me to find a better layer based design for my repository.

I found this excellent blog: Correct use of Repository and Unit Of Work patterns in ASP.NET MVC leading me to the right direction. The redesign is based on the UnitOfWork pattern. It enables me to have just one constructor parameter for all my controllers instead of "never ending constructor parameters". And after that, I was able to introduce proactive caching as well, which solved a great deal of the earlier mentioned trouble I was having.

Now I only have these classes:

• IUnitOfWork
• EFUnitOfWork
• IGenericRepository
• EFGenericRepository

See the referred blog for complete information and implementation of these classes. Just to give an example, IUnitOfWork contains repository definitions for all entities that I need, like:

namespace MyWebApp.Domain.Abstract
{
  public interface IUnitOfWork : IDisposable
  {
    IGenericRepository AAAAARepository { get; }
    IGenericRepository BBBBBRepository { get; }
    IGenericRepository CCCCCRepository { get; }
    IGenericRepository DDDDDRepository { get; } 
    // etc.

    string Commit();
  }
}

The Dependency Injection (DI) is just one statement (I use Ninject):

ninjectKernel.Bind().To();

The Controllers-constructors are maintainable:

public class MyController : BaseController
{
  private MyModel mdl = new MyModel();

  private IUnitOfWork _context; 

  public MyController(IUnitOfWork unitOfWork)
  {
    _context = unitOfWork;

    // intialize whatever needs to be exposed to the View:
    mdl.whatever = unitOfWork.SomeRepository.AsQueryable(); 
  }

 // etc.

Within the Controller I can use _context to access all repositories, if needed. The nice part of it, is that it needs just a single Commit()-call to save changed data for all repositories:

_context.Commit();