Ninject singleton and Entity Framework with MVC and API

Question

I really struggled with the title on this one so hopefully I will describe it much better here!

We use Entity Framework as our ORM and Ninject as our Dependency Injection framework. We bind our DbFactory and UnitOfWork as a singleton with Ninject

Bind<IDbFactory>().To<DbFactory>().InSingletonScope();
Bind<IUnitOfWork>().To<UnitOfWork>().InSingletonScope();

Now, within the MVC project this works great but we also want to use an API to post some data back to the server and then refresh the page. It takes around 10 minutes for EF to decide that it wants to query the database again to retrieve the data.

Other than disabling caching, my only theory to this is Ninject is creating an object for the MVC project to use and another for the API. So my question; is my theory correct and if so, how can I overcome this?

Edit: Example model

public class Property
{ 
    public int Id { get; set; }
    public virtual ICollection<PropertyPhoto> PropertyPhotos { get; set; }
    // Blah blah everything else
}

public class PropertyPhoto
{
    public int Id { get; set; }
    // Blah blah everything else
}

Now, the API is updating the PropertyPhoto model through its repository whereas the mvc project is using the Property model

Have you debugged the project. There are many places that caching could occur. The browser, the HTTP proxy, IIS, .net, ASP.NET MVC, and finally EF. Try and trace out where the requests are actually hitting. — Aron, May 07 '13 at 08:48
It's not the browser - we don't use a proxy - we use IIS Express. I will edit my answer with an example model. — Matt, May 07 '13 at 08:56
"We bind our ... UnitOfWork as a singleton". This might become a problem. A unit of work is by definition not singleton, but rather per request or something similar. Please take a look at [this related post](http://stackoverflow.com/questions/3266295/net-entity-framework-and-transactions/3266481#3266481). — Steven, May 07 '13 at 09:47
So yea... that answered that (you may want to post that as an answer and I will mark it as answered) I'm confused though, I had a look at http://martinfowler.com/eaaCatalog/unitOfWork.html and still couldn't figure out why it is not good practice to have your unitofwork as a singleton — Matt, May 07 '13 at 10:04

score 0 · Answer 1 · answered May 07 '13 at 11:16

0

I took on the advise from Steven and removed the singleton scope but this prevented me from removing entities from the database, in the end I used

Bind<IDbFactory>().To<DbFactory>().InThreadScope();
Bind<IUnitOfWork>().To<UnitOfWork>().InThreadScope();

answered May 07 '13 at 11:16

Matt

2,691
3
22
36

1

ThreadScope is just moving the problem around. You need to be using InRequestScope for request scope stuff and having all your processing done by the end of your action. But it sounds like you have other stuff going on too so you might need to get dirty with http://stackoverflow.com/questions/7951914/ninject-inrequestscope-fallback-to-inthreadscope and/or ttp://stackoverflow.com/questions/15599325/looking-for-a-ninject-scope-that-behaves-like-inrequestscope – Ruben Bartelink May 07 '13 at 11:36
@RubenBartelink - Thanks, will look into this ASAP – Matt May 07 '13 at 13:24

Ninject singleton and Entity Framework with MVC and API

1 Answers1