Enterprise Library Unity vs Other IoC Containers

What's pros and cons of using Enterprise Library Unity vs other IoC containers (Windsor, Spring.Net, Autofac ..)?

I am preparing a presentation for a usergroup. As such I just went through a bunch of them. Namely: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity, and Windsor.

I wanted to show off the 90% case (constructor injection, which is mainly what people use an IOC for anyway). You can check out the solution here (VS2008)

As such, there are a few key differences:

• Initialization
• Object retrieval

Each of them have other features as well (some have AOP, and better gizmos, but generally all I want an IOC to do is create and retrieve objects for me)

Note: the differences between the different libraries object retrieval can be negated by using the CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator

That leaves us with initialization, which is done in two ways: via code or via XML configuration (app.config/web.config/custom.config). Some support both, some support only one. I should note: some use attributes to help the IoC along.

So here is my assessment of the differences:

Ninject

Code initialization only (with attributes). I hope you like lambdas. Initialization code looks like this:

 IKernel kernel = new StandardKernel(
                new InlineModule(
                    x => x.Bind<ICustomerRepository>().To<CustomerRepository>(),
                    x => x.Bind<ICustomerService>().To<CustomerService>(),
                    x => x.Bind<Form1>().ToSelf()
                    ));

StructureMap

Initialization code or XML or Attributes. v2.5 is also very lambda'y. All in all, this is one of my favorites. Some very interesting ideas around how StructureMap uses Attributes.

ObjectFactory.Initialize(x =>
{
    x.UseDefaultStructureMapConfigFile = false;
    x.ForRequestedType<ICustomerRepository>()
        .TheDefaultIsConcreteType<CustomerRepository>()
        .CacheBy(InstanceScope.Singleton);

    x.ForRequestedType<ICustomerService>()
        .TheDefaultIsConcreteType<CustomerService>()
        .CacheBy(InstanceScope.Singleton);

    x.ForConcreteType<Form1>();
 });

Unity

Initialization code and XML. Nice library, but XML configuration is a pain in the butt. Great library for Microsoft or the highway shops. Code initialization is easy:

 container.RegisterType<ICustomerRepository, CustomerRepository>()
          .RegisterType<ICustomerService, CustomerService>();

Spring.NET

XML only as near as I can tell. But for functionality Spring.Net does everything under the sun that an IoC can do. But because the only way to unitize is through XML it is generally avoided by .net shops. Although, many .net/Java shop use Spring.Net because of the similarity between the .net version of Spring.Net and the Java Spring project.

Note: Configuration in the code is now possible with the introduction of Spring.NET CodeConfig.

Windsor

XML and code. Like Spring.Net, Windsor will do anything you could want it to do. Windsor is probably one of the most popular IoC containers around.

IWindsorContainer container = new WindsorContainer();
container.AddComponentWithLifestyle<ICustomerRepository, CustomerRepository>("CustomerRepository", LifestyleType.Singleton);
container.AddComponentWithLifestyle<ICustomerService, CustomerService>("CustomerService",LifestyleType.Singleton);
container.AddComponent<Form1>("Form1");

Autofac

Can mix both XML and code (with v1.2). Nice simple IoC library. Seems to do the basics with not much fuss. Supports nested containers with local scoping of components and a well-defined life-time management.

Here is how you initialize it:

var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
        .As<ICustomerRepository>()
        .ContainerScoped();
builder.Register<CustomerService>()
        .As<ICustomerService>()
        .ContainerScoped();
builder.Register<Form1>();

---

If I had to choose today: I would probably go with StructureMap. It has the best support for C# 3.0 language features, and the most flexibility in initialization.

Note: Chris Brandsma turned his original answer into a blog post.

As far as I've seen they are pretty much the same, except for a few implementation details here and there. The biggest advantage that Unity has over the competition is that it is provided by Microsoft, there are lots of companies out there that are afraid of OSS.

One disadvantage is that it's rather new so it might have bugs that the older players have already sorted out.

Having said that, you might want to check this out.

Old thread but since this is the first thing that Google showed me when I typed in unity vs spring.net...

Spring does do CodeConfig now if you don't like XML config

http://www.springframework.net/codeconfig/doc-latest/reference/html/

Also, Spring is much more than just an DI container, if you look at the 'Modules' section in the docs, the DI container is the foundation of the huge stack of things it does.

Correct me if I'm mistaken but I think Autofac itself supports XML Configuration as listed in this link: Autofac XML Configuration

Spring has one feature that it can inject parameters to constructor or property based on the parameter name or position. This is very useful if the parameter or property is a simple type (e.g. an integer, a boolean). See the example here. I don't think that this really makes up for Spring's inability to do config in code.

Windsor can also do this, and can do it in code not config. (correct me if I'm wrong, I'm just going via what I've heard here).

I would like to know if Unity can do this.

One thing to note: Ninject is the only IoC container that supports contextual dependency injections (as per their Web site). However, because I don't have experience with other IoC containers, I can't tell if that holds.

Just to add my 2 cents, I've tried both StructureMap and Unity. I found StructureMap to be poorly/misguidingly documented, a pain in the butt to configure, and clunky to use. Likewise, it doesn't seem to support scenarios like constructor argument overrides at resolution time, which was a key usage point for me. So I dropped it and went with Unity, and had it doing what I wanted in about 20 minutes.

I personally use Unity, but only because it is from Microsoft. I regret the decision for one reason: the biggest thing it has against it has one big "bug" that causes it to constantly throws exceptions. You can ignore the exceptions while debugging. However it slows down your application tremendously if you run across it, since throwing an exception is an expensive operation. For example, I'm currently "fixing" this exception in one spot in my code where Unity's exceptions adds an extra 4 seconds to a page's render time. For more details and a workaround, see:

https://stackoverflow.com/questions/2873767/can-unity-be-made-to-not-throw-synchronizationlockexception-all-the-time