Ninject kernel creation inside a class library

Question

I have a class that has dependencies that I've wired up with Ninject.

public interface IFoo {}

public class MyObject {
    [Inject]
    IFoo myfoo;
}

In the real implementation I'm using property injection, but just to quickly illustrate, I'll inject on the field. As I understand, instead of newing instances of MyObject, in order to get the dependencies to be properly injected, I need to use

kernel.Get<MyObject>()

The thing I'm stumbling on however is that MyObject will only be used in the context of a class library. The intention is for end applications to create their own modules and pass it into a kernel instance to hydrate. Given that, what's generally the most pragmatic way to approach surfacing a generic instance of a Ninject kernel to my class library so that instances of MyObject (and other similar cases) can be hydrated?

My first inclination is some sort of factory that internalizes a singleton kernel--which the applications themselves have to hydrate/initialize by loading up a module.

So in RandomService.cs

var myKernel = NinjaFactory.Unleash();
var myobj = myKernel.Get<MyObject>();
myobj.foo();

Before I go too far down this path though, I need to do a sanity check to make sure that the thinking is sound or that there isn't some obvious other thing that I'm missing. I'm obviously new to IoC and feel like I grok the basics, but not necessarily the best real world ways to use it.

Answer 1

I'm not sure that I understand all the details in your question, but I as far as I understand, you are asking how you can externalize the dependency on Ninject.

It is possible to write DI-friendly libraries without ever referencing any particular DI Container (Ninject or anything else). This leaves the consumer of the library open to choose the DI Container of his or her liking (or not use a container at all). This approach is much preferred because it provides a greater degree of freedom.

However, you should really favor Constructor Injection over Property Injection. Although Property Injection seems deceptively simple to implement, it's actually quite difficult to get right.

One of the great advantages of Constructor Injection is that you don't need to put any attributes on the constructor because it structurally already carries all the information needed for a DI Container to correctly wire it up.

Answer 2

I wouldn’t make your library dependent on Ninject. IMO it's better to let your library talk with a facade that allows users of the library to chose a particular IoC implementation.

The Common Service Locator is such a facade over IoC libraries. The popular IoC libraries, such as Ninject, support the Common Service Locator.

When using the Common Service Locator, your library can this, as follows:

var myObj = ServiceLocator.Current.GetInstance<MyObject>();

Using the Common Service Locator, your clients can register their implementation in the startup path of their application as follows:

var container = new [YourFavoriteContainerHere];

ServiceLocator.SetServiceProvider(() => container);

It depends on your library, but if your company sells this library as a product on itself, you even not want to have a dependency on any external library (such as CSL or Ninject). In that case it’s perhaps better to let your users register the needed dependencies in a configuration file. In that situation patterns as the .NET Provider Pattern come in mind (which is practically a configuration based IoC pattern). I built a .NET Provider Model Template for Visual Studio a few years ago that could give you a kick start, when you think this pattern is appropriate.

Or you could simply do the simplest thing possible and create an initialization point in your library that your clients must call in the startup path of their application, just like the ServiceLocator has, but then without the external dependencies:

MyComp.MyLib.IFeatureFactory clientImplementation = new MyClientFeatureFactory();
MyComp.MyLib.FeatureFactory.Initialize(clientImplementation);

I hope this helps.

Answer 3

Mark's point is definitely my starting view (hence a +1) on that.

I for one have been guilty in the past of giving up on constructor over properties (or fields) too soon (my "excuse" was that as a base class needed 5 properties I didnt want to burden all derived classes with that. The solution to that was to wrap the 5 properties involved in a class or hierarchy of classes representing whatever underlying concepts the properties represent. A bit like the Introduce Parameter Object refactoring.

A good discussion of the considerations I found useful is http://thinkbeforecoding.com/post/2009/05/15/IOC-container-go-hide (cant Locate the SO post that mentions it and some topics around it, maybe someone will Inject a link :D)

Another blog that sums up some of these points is Your IoC Container is Showing

And http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/

http://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library/2047657#2047657