Ninject kernel creation inside a class library

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 开发者_如何学JAVAinstance 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.

---

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.

---

Mark's point is definitely my starting view (hence a +1) on that. NB dont forget to follow his link.

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/

---

Here is a nice general purpose recipe for finding all ninject modules in the current assembly :

IKernel _serviceKernel = new StandardKernel();

Assembly myAssembly = this.GetType().Assembly;

IEnumerable<Type> ninjectModuleTypes = 
     myAssembly.GetTypes().Where(type => type.BaseType == typeof(NinjectModule));

foreach (Type ninjectModuleType in ninjectModuleTypes)
{
    NinjectModule mod = (NinjectModule)Activator.CreateInstance(ninjectModuleType);
    _serviceKernel.Load(mod);
}