title: Entity Framework DbContext Lifetime in ASP.NET MVC Using Ninject?
body: <p>I have the following unit of work pattern set up for an MVC 5 application using Entity Framework. The unit of work has all the repos defined as follows so that they are all using the same dbcontext and it has one save method to co-ordinate the transaction using the same context:</p>
  
  <pre><code>public class UnitOfWork : IUnitOfWork
  {
      private readonly ApplicationDbContext _context;
  
      public IProductRepository ProductRepository { get; private set; }
      public ICustomerRepository CustomerRepository { get; private set; }
      // Other reposistories
  
      public UnitOfWork(ApplicationDbContext context)
      {
          _context = context;
          ProductRepository = new ProductRepository(_context);
          CustomerRepository = new CustomerRepository(_context);
  
          // Other reposistories
      }
  
      public void Complete()
      {
          _context.SaveChanges();
      }
  }
  </code></pre>
  
  <p>This is an example of my repo. The reason for using repos is for code re-use so that I'm not duplicating queries inside different controllers.</p>
  
  <pre><code>public class ProductRepository : IProductRepository
  {
      private readonly ApplicationDbContext _context;
  
      public ProductRepository(ApplicationDbContext context)
      {
          _context = context;
      }
  
      public Product GetProduct(int productId)
      {
         return _context.Ticket.SingleOrDefault(p =&gt; p.Id == productId);
      }
  
       public void Add(Product product)
      {
          _context.Product.Add(product);
      }
  
      // Other methods
  }
  </code></pre>
  
  <p>I inject the unit of work class in my controller as follows using Ninject:</p>
  
  <pre><code> public class ProductsController : Controller
  {
  
      private readonly IUnitOfWork _unitOfWork;
      private readonly IFileUploadService _FileUploadService;
  
      public ProductsController(IUnitOfWork unitOfWork, 
              IFileUploadService fileUploadService)
      {
          _unitOfWork = unitOfWork; 
          _FileUploadService = fileUploadService;
      }
  
      [HttpPost]
      [ValidateAntiForgeryToken]
      public ActionResult Create(CreateEditProductViewModel viewModel)
      {
            var product = new Product
            {
                // Do stuff
            };
  
            _unitOfWork.ProductRepository.Add(product);
  
            // Call file upload service
            _fileUploadService.Upload();
  
            _unitOfWork.Complete();
  
      }
  
   }
  </code></pre>
  
  <p>This unit of work set up works fine if all I'm using are repos that are defined in the unit of work class. But now I want to use a service class to process some additional application logic and then the unit of work is committed in the controller action. If I define the class as follows it will be using a different instance of the context, In which case how would you co-ordinate a transaction where the service layers is ending up with a different context?</p>
  
  <pre><code>public class FileUploadService : IFileUploadService
  {
      private readonly IUnitOfWork _unitOfWork;
  
      public FileUploadService(IUnitOfWork unitOfWork)
      {
          _unitOfWork = unitOfWork;
      }
  
      public uploadResult Upload()
      {   
          // Some stuff
           var uploadedFile = new UploadedFile
           {
              //some stuff
           };
  
           _unitOfWork.UploadedFileRepository.Add(uploadedFile);
      }
   }  
  </code></pre>
  
  <p>I've done quite a bit of research online and I'm unable to find any resource that provides a practical example to solve this problem. I've read quite a bit of stuff on ditching unit of work and repos and simply using entity frameworks dbset. However as explained above the purpose of using
  repos is to consolidate queries. My questions is how do I co-ordinate the unit of work with a service class. </p>
  
  <p>I would like the service to use the same context so that it can access the repositories it needs to work with, and let the controller (client code) commit the operation when it see fits.</p>
  
  <p><strong>* UPDATE *</strong></p>
  
  <p>In my DI Container I resolve all interfaces using the following snippet:</p>
  
  <pre><code>    private static IKernel CreateKernel()
      {
  
              RegisterServices(kernel);
  
              kernel.Bind&lt;IUnitOfWork&gt;().To&lt;UnitOfWork&gt;().InRequestScope();
  
              // default binding for everything except unit of work
              kernel.Bind(x =&gt; x.FromAssembliesMatching("*")
               .SelectAllClasses()
               .Excluding&lt;UnitOfWork&gt;()
               .BindDefaultInterface());
  
              return kernel;
  
      } 
  </code></pre>
  
  <p>Would adding the line <code>kernel.Bind&lt;IUnitOfWork&gt;().To&lt;UnitOfWork&gt;().InRequestScope();</code> ensure that no more than one ApplicationDbContext is created, even if the request ends up hitting multiple controllers or service layers that all require an IUnitOfWork (ApplicationDbContext)?</p>