Why do I need an IoC container as opposed to straightforward DI code? [closed]

Answer 1

IoC Containers are also good for loading deeply nested class dependencies. For example if you had the following code using Depedency Injection.

public void GetPresenter()
{
    var presenter = new CustomerPresenter(new CustomerService(new CustomerRepository(new DB())));
}

class CustomerPresenter
{
    private readonly ICustomerService service;
    public CustomerPresenter(ICustomerService service)
    {
        this.service = service;
    }
}

class CustomerService
{
    private readonly IRespository<Customer> repository;
    public CustomerService(IRespository<Customer> repository)
    {
        this.repository = repository;
    }
}

class CustomerRepository : IRespository<Customer>
{
    private readonly DB db;
    public CustomerRepository(DB db)
    {
        this.db = db;
    }
}

class DB { }

If you had all of these dependencies loaded into and IoC container you could Resolve the CustomerService and the all the child dependencies will automatically get resolved.

For example:

public static IoC
{
   private IUnityContainer _container;
   static IoC()
   {
       InitializeIoC();
   }

   static void InitializeIoC()
   {
      _container = new UnityContainer();
      _container.RegisterType<ICustomerService, CustomerService>();
      _container.RegisterType<IRepository<Customer>, CustomerRepository>();
   }

   static T Resolve<T>()
   {
      return _container.Resolve<T>();
   }
}

public void GetPresenter()
{
   var presenter = IoC.Resolve<CustomerPresenter>();
   // presenter is loaded and all of its nested child dependencies 
   // are automatically injected
   // -
   // Also, note that only the Interfaces need to be registered
   // the concrete types like DB and CustomerPresenter will automatically 
   // resolve.
}

Answer 2

IoC frameworks are excellent if you want to...

• ...throw away type safety. Many (all?) IoC frameworks forces you to execute the code if you want to be certain everything is hooked up correctly. "Hey! Hope I got everything set up so my initializations of these 100 classes won't fail in production, throwing null-pointer exceptions!"

• ...litter your code with globals (IoC frameworks are all about changing global states).

• ...write crappy code with unclear dependencies that's hard to refactor since you'll never know what depends on what.

The problem with IoC is that the people who uses them used to write code like this

public class Foo {
    public Bar Apa {get;set;}
    Foo() {
        Apa = new Bar();
    }
}

which is obviously flawed since the dependency between Foo and Bar is hard-wired. Then they realized it would be better to write code like

public class Foo {
    public IBar Apa {get;set;}
    Foo() {
        Apa = IoC<IBar>();
    }
}

which is also flawed, but less obviously so. In Haskell the type of Foo() would be IO Foo but you really don't want the IO-part and is should be a warning sign that something is wrong with your design if you got it.

To get rid of it (the IO-part), get all advantages of IoC-frameworks and none of it's drawbacks you could instead use an abstract factory.

The correct solution would be something like

data Foo = Foo { apa :: Bar }

or maybe

data Foo = forall b. (IBar b) => Foo { apa :: b }

and inject (but I wouldn't call it inject) Bar.

Also: see this video with Erik Meijer (inventor of LINQ) where he says that DI is for people who don't know math (and I couldn't agree more): http://www.youtube.com/watch?v=8Mttjyf-8P4

Unlike Mr. Spolsky I don't believe that people who use IoC-frameworks are very smart - I simply believe they don't know math.

Answer 3

IOC CONTAINER SOLVES A PROBLEM YOU MIGHT NOT HAVE BUT IT'S A NICE PROBLEM TO HAVE

http://kozmic.net/2012/10/23/ioc-container-solves-a-problem-you-might-not-have-but-its-a-nice-problem-to-have/

Answer 4

As you continue to decouple your classes and invert your dependencies, the classes continue to stay small and the "dependency graph" continues to grow in size. (This isn't bad.) Using basic features of an IoC container makes wiring up all these objects trivial, but doing it manually can get very burdensome. For example, what if I want to create a new instance of "Foo" but it needs a "Bar". And a "Bar" needs an "A", "B", and "C". And each of those need 3 other things, etc etc. (yes, I can't come up with good fake names :) ).

Using an IoC container to build your object graph for you reduces complexity a ton and pushes it out into one-time configuration. I simply say "create me a 'Foo'" and it figures out what's needed to build one.

Some people use the IoC containers for much more infrastructure, which is fine for advanced scenarios but in those cases I agree it can obfuscate and make code hard to read and debug for new devs.

Answer 5

It sounds to me like you already built your own IoC container (using the various patterns which were described by Martin Fowler) and are asking why someone else's implementation is better than yours.

So, you have a bunch of code that already works. And are wondering why you would want to replace it with someone else's implementation.

Pros for considering a third-party IoC container

• You get bugs fixed for free
• The library design may be better than yours
• People may be already familiar with the particular library
• The library may be faster than yours
• It may have some features you wish you implemented but never had time to (do you have a service locater?)

Cons

• You get bugs introduced, for free :)
• The library design may be worse than yours
• You have to learn a new API
• Too many features you will never use
• It's usually harder to debug code you did not write
• Migrating from a previous IoC container may be tedious

So, weigh your pros against your cons and make a decision.

Answer 6

Dittos about Unity. Get too big, and you can hear the creaking in the rafters.

It never surprises me when folks start to spout off about how clean IoC code looks are the same sorts of folks who at one time spoke about how templates in C++ were the elegant way to go back in the 90's, yet nowadays will decry them as arcane. Bah !