Why some ioc frameworks are so complex?because just a few line of code seems can do this too

Question

The ioc frameworks I mentioned are Unity, Autofac, structuremap and so on.

The code is:

public class Ioc
{
    private static readonly Dictionary<Type, Type> mapper = new Dictionary<Type, Type>();

    public static T CreateInstance<T>()
    {
        var t = typeof (T);
        if (mapper.ContainsKey(t))
        {
            return (T) Activator.CreateInstance(mapper[t]);
        }
        return Activator.CreateInstance<T>();
    }

    public static void Map<TInterface, TImplementation>() where TImplementation : TInterface
    {
        var inferfaceType = typeof (TInterface);
        var implementationType = typeof (TImplementation);
        if (mapper.ContainsKey(inferfaceType))
        {
            mapper[inferfaceType] = implementationType;
        }
        else
        {
            mapper.Add(inferfaceType, implementationType);
        }
    }
}

And it can be used like this:

Ioc.Map<IUserService, UserService>();
Ioc.Map<IUserBusiness, UserBusiness>();

and

var userService = Ioc.CreateInstance<IUserService>()

It is used just like the way the ioc frameworks are used.

Is there a big performance difference between them?

Answer 1

Whether or not there is a 'big difference' in performance is completely depending on context. The question is: is it fast enough in your case and does this solve all your needs?

Take a look at this very interesting comparison between different DI libraries for .NET. It compares performance between the major 8 libraries and many other small ones.

But besides performance, there are many other features that you should be aware of that might help you a lot. Some libraries for instance (Castle Windsor and Simple Injector) contain 'Diagnostic Services' that help you find possible misconfigurations that are otherwise very hard to detect (such as captive dependencies and many others). And Simple Injector for instance follows a very strict design principles that tries to minimize the configuration errors you can make as a user.

Other features that make the internal implementation of a DI library much more complex are features such as lifestyle management, auto-wiring, cyclic dependency detection, resolving collections, resolving generic types. And don't forget the integration with all kinds of different frameworks and technologies.

So in general, I don't advice to use your own mini DI library. Either you use one of the existing DI libraries out there, or you don't use a container at all. Do note that don't using a DI library is not the same as not using the Dependency Injection pattern! You should absolutely apply Dependency Injection, but whether or not a DI library is beneficial for your application is dependent on the size of your application. If the application is small, it is not a shame to hand-wire all object graphs manually in the Composition Root. As a benefit you get compile-time support for free.