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());

in that case as a guess I can only think it is actually down to the lifecycle of the IPupilBlockService implementation and the client that uses it. HTH — Pero P., Dec 23 '10 at 09:27

score 14 · Accepted Answer · edited May 23 '17 at 12:24

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.

I love the principle of least surprise! Great answer, I like the thinking and the pattern. I will test to see if it solves my issue, if it does, you'll get the biscuit. For now, +1. — awrigley, Dec 23 '10 at 13:11
btw. Unscientific research as proven that 86.3% of all problems about IoC containers can be solved by using factories :-) — Steven, Dec 23 '10 at 13:34
Worked a dream. Neatly separated concerns. The parameters under my control. Minimal Dependency Injection required. My knowledge expanded incrementally rather than dramatically. Surprise is minimized. I move on. Merry Christmas. — awrigley, Dec 24 '10 at 09:52

score 3 · Answer 2 · answered Jul 29 '12 at 09:22

@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());

score 1 · Answer 3 · edited Mar 22 '11 at 10:01

1

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)

edited Mar 22 '11 at 10:01

Constantin

27,478
10
60
79

answered Dec 23 '10 at 08:47

Pero P.

25,813
9
61
85

No, I have just used the Ninject default settings. See Edit. – awrigley Dec 23 '10 at 09:09

Ninject caching an injected DataContext? Lifecycle Management?

Edit:

3 Answers3

Linked