What is the use of an IoC framework in an MVC application? [closed]

Question

I'm trying to understand the use of an IoC framework like StructureMap, but i can't help thinking that these "design patterns" are just nonsense, making code just more complex.

Let me start with an example where i think an IoC is somewhat usefull.

I think an IoC can be usefull when dealing with the instantiation of controller classes in an MVC framework. In this case i'm thinking about the .NET MVC framework.

Normally the instantiation of the controller class is handled by the framework. So that means you can't really pass any parameters to the constructor of your controller class. This is where an IoC framework can come in handy. Somewhere in an IoC container you specify what class should be instantiated and passed to your controllers constructor when the controller class is invoked.

This is also handy when you want to unit test the controller, because you can mock the object that is passed to it.

But like i said, i can somewhat understand why people want to use it for their controller classes. But not outside of that. From there on you can simply do normal Dependency Injection.

But why not simply do it like this:

public class SomeController
{
    public SomeController() : this( new SomeObj() ) 
    {
    }

    publiv SomeController(SomeObj obj)
    {
        this.obj = obj;
    }
}

Now you don't have to use any 3rd party IoC framework which also means a lower learning curve. Since you don't have to go into the specs of that framework aswell.

You can still mock the object in your Unit Tests. So no problem there either.

The only thing you can say is, "but now your class is tightly coupled to SomeObj". This is true. But who cares!? It's a controller class! I'm not going to reuse that class, ever.. So why on earth should i worry about that tight coupling..? I can mock the object that is passed to it. That's the only important thing.

So why should i bother using an IoC? Am i REALLY missing the point...? To me the IoC pattern is just some overrated pattern. Adding more, complex layers to your application...

Answer 1

You ask a good question and in your example I would say that an IoC would / could be overkill, but just consider your code extended to the following and then you might begin to see the benefit of having an IoC do all this for you.

public class SomeController
{
    public SomeController() : this( new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo())) ) 
    {
    }

    publiv SomeController(SomeObj obj)
    {
        this.obj = obj;
    }
}

Answer 2

There are multiple things an IoC container can do for you.

The obvious one is providing the implementation for the dependencies, which makes sense elsewhere, not just in controllers - If you decide to replace SomeObj with SomeObj2, you can do it in just one place, instead of 57 places .

Another one is handling the lifecycle concerns, i.e. you can specify the scope of an object (singleton, per-thread, per-request, transient...).

Additionally, IoC container can set your optional dependencies (i.e. property injection), which is easier than writing this :

var svc = new Service(new MyRepository())
svc.Logger = logger;
svc.XY = xy

and all the good reasons stated here: Why do I need an IoC container as opposed to straightforward DI code?