Simple Dependency Resolver

Question

How do you create simple Dependency Resolver, with out using any built in or library such as Autofac, Ninject, etc.

This was my interview question.

I wrote t

Answer 1

DI Containers are complex libraries. Building them takes years and maintaining them decades. But to demonstrate their working, you can write a simplistic implementations in just a few lines of code.

At its core a DI Container would typically wrap a dictionary with System.Type as its key and, the value would be some object that allows you to create new instances of that type. When you write a simplistic implementation System.Func<object> would do. Here is an example that contains several Register methods, both a generic and non-generic GetInstance method and allows Auto-Wiring:

public class Container 
{
    Dictionary<Type, Func<object>> regs = new Dictionary<Type, Func<object>>();

    public void Register<TService, TImpl>() where TImpl : TService =>
        this.regs.Add(typeof(TService), () => this.GetInstance(typeof(TImpl)));

    public void Register<TService>(Func<TService> instanceCreator) =>
        this.regs.Add(typeof(TService), () => instanceCreator());

    public void RegisterInstance<TService>(TService instance) =>
        this.regs.Add(typeof(TService), () => instance);

    public void RegisterSingleton<TService>(Func<TService> instanceCreator) {
        var lazy = new Lazy<TService>(instanceCreator);
        this.Register<TService>(() => lazy.Value);
    }

    public object GetInstance(Type type) {
        Func<object> creator;
        if (this.regs.TryGetValue(type, out creator)) return creator();
        else if (!type.IsAbstract) return this.CreateInstance(type);
        else throw new InvalidOperationException("No registration for "+ type);
    }

    private object CreateInstance(Type implementationType) {
        var ctor = implementationType.GetConstructors().Single();
        var parameterTypes = ctor.GetParameters().Select(p => p.ParameterType);
        var dependencies =
            parameterTypes.Select(t => this.GetInstance(t)).ToArray();
        return Activator.CreateInstance(implementationType, dependencies);
    }
}

You can use it as follows:

var container = new Container();

container.RegisterInstance<ILogger>(new FileLogger("c:\\logs\\log.txt"));

// SqlUserRepository depends on ILogger
container.Register<IUserRepository, SqlUserRepository>();

// HomeController depends on IUserRepository
// Concrete instances don't need to be resolved
container.GetInstance(typeof(HomeController));

WARNING:

Please note that you should never actually use such naive and simplistic implementation. It lacks many important features that DI libraries give you, yet gives no advantage over using Pure DI (i.e. hand wiring object graphs). You loose compile-time support, without getting anything back.

When your application is small, you should start with Pure DI and once your application and your DI configuration grow to the point that maintaining you Composition Root becomes cumbersome, you could consider switching to one of the established DI libraries.

Here are some of the features that this naive implementation lacks compared to the established libraries:

• Auto-Registration; registering a set of types with a single line
• Interception; the ability to apply decorators or interceptors for a range of types
• Generics; Mapping open-generic abstractions to open generic implementations
• Integration; using the library with common application platforms (such as ASP.NET MVC, Web API, .NET Core, etc)
• Lifestyle management; The ability to registering types with custom lifestyles.
• Error handling; Detection of misconfiguration such as cyclic dependnecies. The simplistic implementation throws a stack overflow exception.
• Verification; Features or tools for verifying the correctness of the configuration (to compensate the loss of compile-time support) and diagnosing common configuration mistakes.
• Performance; Building large object graphs will be slow using this simplistic implementation.

These features and abilities allow you to keep your DI configuration maintainable when using a DI Container.

Answer 2

It's already a few years old, but Ayende once wrote a blog post about this:
Building an IoC container in 15 lines of code

But this is only the very simplest possible implementation.
Ayende himself stated in his next post that the existing IoC containers can do much more stuff than just returning class instances - and this is where it gets complicated.
As "Trust me - I'm a Doctor" already said in his comment: implementing a complete IoC container is everything but trivial.