Using IoC advanced features with own abstraction

Question

I've read many interesting articles about using IoC containers in the development. In many cases authors advise us to write your own simple wrapper which hides an interface to the read container like Ninject, Castle.Windsor, Unity etc.

The implementation of wrapper looks like this (for Ninject):

/// <summary>
/// Contains links for service contract and realization.
/// </summary>
public static class IoC
{
    static readonly IKernel kernel;
    static IoC()
    {
        kernel = new StandardKernel();
    }

    public static void RegisterService<T>(Type service)
    {
        kernel.Bind<T>().To(service);
    }

    public static T Resolve<T>()
    {
        return kernel.Get<T>();
    }
}

Okay, but how can I use advanced features with this pattern? For example I love to use life-time managment modifiers like InRequestScope() or InSingletonScope() and many containers support the same. With the pattern above I can throw away ninject and use 15-lines implementation. Where is the difference?

I also looked at CommonServiceLocator trying to find rich wrapper but it has no much difference with mine IoC class. Now I think that I should not make my own bike and use full featured containers directly. What about you?

Answer 1

Your application code should be completely oblivious to the existence of a DI Container, no matter which one. Instead, classes that need dependencies should request them through Constructor Injection, like this:

public class Foo
{
    private readonly IBar bar;

    public Foo(IBar bar)
    {
        if (bar == null)
            throw new ArgumentNullException("bar");

        this.bar = bar;
    }

    public void SomeMethod()
    {
        // use this.bar from here...
    }
}

Notice how the combination of the Guard Clause and the readonly keyword protects the invariants of the class. From any method of the Foo class, this.Bar is guaranteed to be available.

All DI Containers understand this design pattern, so you can let your container of choice compose the entire application graph from the Composition Root. From here you can use all the advanced features of the container without worrying that the rest of the code base becomes coupled to the container.