In Ninject, how can I run custom code on an object after it is created with Bind<..>.ToSelf()?

6
votes

In Ninject's dependency injection, if you set up a binding of a class to itself like so:

Bind<SomeClass>().ToSelf();

Ninject very nicely resolves any dependencies SomeClass has and gives you the object back. I want to be able to do something to the SomeClass it returns every time it creates a new one, so like a post-processing event. I could use the .ToMethod (or ToFactoryMethod) binding to explicitly new it up, but I would like all its dependencies resolved by Ninject beforehand.

It wouldu be nice to do something like:

Bind<SomeClass>()
    .ToSelf()
    .After(sc => sc.MethodIWantToCall()); // then after here, Ninject returns the object.

Is there some way to do this in Ninject 1.0/1.1?

2
dependency-injectionninject
Is there a problem with performing the task you want to perform in the constructor? – Peter Meyer
I suppose there isn't anything wrong with it and that's the practical solution :) But I thought that, perhaps, for testing or maybe some real scenarios, the MethodIWantToCall() could be considered a part of the object activation, which I'm turing over to Ninject, rather than implementation. But I would agree it's perhaps a minor point. – ZeroBugBounce

2 Answers

14
votes

If you can't put the code you want to execute in the constructor, you can implement IInitializable or IStartable. The former provides an Initialize() method that gets called after all injection has completed, and the latter provides both a Start() and Stop() method, called during activation and deactivation, respectively.

10
votes

I ran into the same problem, but I could not use Nate's solution because I couldn't make the type implement IInitializable. If you're in a similar boat, you can use .OnActivation and avoid having to modify the definition of the target types:

Bind<SomeClass>().ToSelf().OnActivation(x => ((SomeClass)x).MyInitialize());

You can see how we call some arbitrary initialization method (MyInitialize) upon activation (instantiation) of the class.

This has the advantage of not baking in a hard dependency to Ninject in your own classes (aside from your modules, of course), thus allowing your types to remain agnostic about the DI-framework you end up using.