Examples of IoC Containers [closed]

Question

I've used StructureMap quite a bit. The rest of your question is pretty loaded. I'll try to explain the concept in an example.

Suppose you created a website that will accept payments through PayPal. PayPal is now a dependency. But you don't want to code against a specific PayPal provider.

Instead, you would create and code against an interface like this:

interface IPaymentProcessor
{
    bool ProcessPayment(amount, ....);
}

All your PayPal code would reside in a class that implements the methods of your interface - PayPalPaymentProcessor, for example.

Now you have an object that you will actually use to process the payments. This could be a Controller (ASP.NET-MVC, ViewModel-WPF) or just a class as shown here:

class PaymentProcessor
{
    private IPaymentProcessor _processor = null;
    public PaymentProcessor(IPaymentProcessor processor)
    {
        _processor = processor;
    }

    public bool ProcessTransaction(Transaction trans)
    {
       _processor.ProcessPayment(trans.amount, ...);
    }
}

This is where an IoC container comes in. Instead of you calling the constructor manually, you would let an IoC container inject the dependency:

PaymentProcessor processor = ObjectFactory.GetInstance<PaymentProcessor>();

This piece of code tells StructureMap "Anytime you see a constructor that needs an IPaymentProcessor, return a new PayPalPaymentProcessor".

ObjectFactory.Initialize(x =>
{ 
    x.ForRequestedType<IPaymentProcessor>().TheDefaultIsConcreteType<PayPalPaymentProcessor>();
});

All this mapping is separate from your implementation code and you could swap out these at a later point with little refactoring needed. There is a lot more to IoC containers, but that the basic concept. You can automate the injection of constructors to avoid the calls directly to ObjectFactory as well.

Hope this helps!

Be aware of the following limitations of the IOC container. I have to warn people, because I am living with the hell of having to support a system using it:

• Exceptions thrown by constructors get swallowed. You only get the “couldn’t create dependency” exception. That means you can't catch expected exceptions if it's throw in a constructor.
• Can’t step through constructors.
• Forgetting to register an interface breaks at runtime instead of compile time.
• All your classes can only have one constructor and they all have to accept interfaces as parameters.
• All dependencies are instantiated so you can’t share instances, which means your memory usage can get large quickly.
• It promotes a lot of interdepencies which can hide the fact that you code has turned into spaghetti. Making it easier to instatiate all of these interdepencies just masks that there is a potential underlying problem.
• You can't manage your own "Unit of Work" very easily because you can't manage a transaction across multiple dependencies since you didn't have control of instantiating them and passing in the context of that transaction.

Don't get me wrong, I love dependency injection and the inversion of control principle, but I think the IOC container could be used responsibly, but just be aware of the battles that you will need to fight because of the above list.

If you want to see an IoC container under the hood, and also the point (Dependency Injection), there's a great podcast on DNR TV (Episode 126) that really goes into detail about how to create them, why you'd need them. It's a really wonderful podcast. Once you've watched this video, you'll then be able to look at Unity,Ninject, StructureMap, etc and be able to understand what they're doing

Check out Spring IoC (.net) a java/.net container. The documentation is quite good introduction.

In a brief: You can think about IoC as an architecture that encourage: objects composition and programming to an interface.

This gives you the following:

• the ability to unit test your code easily (you can easily test your objects in isolation by mocking up all its dependencies).

• An extremely advance configuration (because your program with IoC is just bunch of objects and an configuration that glues the objects together).

• The ability to extend or modify byte compiled application (this is true for Java I'm not sure if it is true for .net).

We use Ninject because of its simple API and fast resolution of objects. It's very well documented and leverages C# 3.0 features like lambda expressions to make specification easier.

You can find several screencasts on Ninject here