Examples of IoC Containers

Question

Does anyone have good examples of IoC containers (preferably in c#) and how and why to use them ? I have checked out the wiki page and Ayende's example, but I don't quite get the concept yet.

And when and where should I use an IoC container ?

Answer 1

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).

Answer 2

Are you trying to build a IoC container why not use one of the available ones like Spring.NET, StructureMap or Unity Application Block? Here is a list of open-source IoC projects

Answer 3

I've used structure map 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 comes in. Instead of you calling the constructor manually, you would let an IoC inject the dependency.

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

This piece of code tells structure map "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 IoCs, but that is a basic concept. You can automate the injection of constructors to avoid the calls directly to ObjectFactory as well.

Hope this helps!

Answer 4

I normally use StructureMap - mostly because I'm familiar with the syntax. I've also heard good things about autofac and I'm looking forward to trying out Ninject when it hits v2.

You might want to take a look at this answer where I talk about a basic usage of an IoC container (I always think things are easier to understand with a simple example) - that might help you to understand things a little more. Basically, the IoC container helps you to build objects with all the dependencies satisfied, and allows you to change your dependencies with minimal configuration code.

Answer 5

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

Answer 6

Try reading Introduction to Unity Application Block and in ASP.NET StoreFront: Dependency Injection screencast you can see more about Dependency Injection concepts.

Answer 7

I am using Unity for my IoC container, but the difference between the containers resides in more than what you can do with DI.

DI (Dependency Injection) is mainly a way to get more loose coupling between disparate parts of your program. So, if you wrote a game that you like how it works, by using DI you can change the characters or physics engine in the game without changing other parts of the game, so, if someone pays more money they get the more realistic engine, or the better characters, but since nothing else is changing, the testing is simpler.

Unit testing is also easier with DI as you can mock out the database, for example, by just changing the implementation that will be used by the application, without affecting anything else.

If you use Spring.NET for example, you will get access to a very powerful framework, but it may do a great deal that you won't use, so look for something smaller. I think the best rule is to find the smallest, simplest implementation that meets your needs, and use that.

Answer 8

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

Answer 9

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.