Ninject caching an injected DataContext? Lifecycle Management?

Question

I had a series of very bizarre errors being thrown in my repositories. Row not found or changed, 1 of 2 updates failed... Nothing made sense.

It was as if my DataContext instance was being cached... Nothing made sense and I was considering a career move.

I then noticed that the DataContext instance was passed in using dependency injection, using Ninject (this is the first time I have used DI...). I ripped out the Dependency Injection, and all went back to normal. Instantly.

So dependency injection was the issue, but I still don't know why. I am speculating that Ninject was caching the injected DataContext.

Is this correct?

Edit:

The Ninject binding is as follows:

Bind<IPupilBlockService>().To<SqlPupilBlockService>()
   .WithConstructorArgument("db", new dbDataContext());

Answer 1

For any object which lifetime must explicitly managed (such as objects that implement IDisposable) or matters to the user, try not to inject them, but inject a factory that allows creating such objects instead. Define this interface for instance:

public interface IDbDataContextFactory
{
    dbDataContext CreateNew();
}

And use it as follows:

public class SqlPupilBlockService
{
    private IDbDataContextFactory contextFactory;

    public SqlPupilBlockService(
        IDbDataContextFactory contextFactory)
    {
        this.contextFactory = contextFactory;
    }

    public void DoSomeOperation()
    {
        using (var db = this.contextFactory.CreateNew())
        {
           // use the dbDataContext here.
        }
    }
}

An implementation of would be very simple, like this:

public class DbDataContextFactory : IDbDataContextFactory
{
    public dbDataContext CreateNew()
    {
        return new dbDataContext();
    }
}

And registration goes like this:

Bind<IDbDataContextFactory>().To<DbDataContextFactory>();

The use of a factory makes it very explicit who is the owner of the created object and who should control its lifetime. This makes your code more readable and follows the principle of least surprise.

UPDATE

More than a year has past since I submitted this answer. Instead of using factories, I now often inject the data context itself, and register it on a per (web) request basis. However; a shift in how you need to design your application might be needed, so as always: it depends. Please take a look at this answer.

Answer 2

@Steven gave a great explanation, but actually, Ninject already gives you a way to specify that an instance be generated for per-request: InRequestScope.

Bind<IPupilBlockService>()
   .To<SqlPupilBlockService>()
   .InRequestScope()
   .WithConstructorArgument("db", new dbDataContext());

Answer 3

Take a look at Activation Behaviours. It's possible your DataContext is being bound in a Singleton scope, or one of the other scopes that will result in the same instance being returned from the kernel depending on your call context.

(I'm not too familiar with ninject but given transient scope is the default, I'd expect somewhere in your app code the DataContext is explicitly defined as having a non-transient scope)