Question

I was wondering how far I should take my IoC implementation in terms of loosely coupling my application. I am using constructor injection in my MVC controller but wondered if I should also be resolving all my other dependencies in the controller instead of newing up objects. For example if I was to create a new User object within a controller method would I use?

var user = new User();
var user = myContainer.Resolve<IUser>();

I like the idea of breaking my dependency on User but is that going too far and could possible make my code harder to read?

Answer 1

This is a very good question, when you read and hear about DI it makes sense and this is the next natural conclusion.

First Steven’s point is correct you should not pass the container around. If you need to construct IUser on the fly and it needs to be abstract you should rather inject an Abstract Factory.

Sebastian also posted a good link.

I actually wrote about this in an answer I posted here.

The bottom section of the post:

Not every object and dependency needs or should be dependency injected, first consider if what you are using is actually considered a dependency:

What are dependencies?

Application Configuration
System Resources (Clock)
Third Party Libraries
Database
WCF/Network Services
External Systems (File/Email)

Any of the above objects or collaborators can be out of your control and cause side effects and difference in behavior and make it hard to test. These are the times to consider an Abstraction (Class/Interface) and use DI.

What are not dependencies, doesn’t really need DI?

List
MemoryStream
Strings/Primitives
Leaf Objects/Dto's

So in your particular case it really depends on what happens when IUser is constructed also whether you actually need to substitute it with different implementations. If this is not the case and User has only simple types with no external dependencies or side effects just new it up.

Consider what happens when you call new User(), look at the graph below, if it causes other objects to be created and looks like something in the graph below consider IoC.

A cascading dependency object graph:

In this example new on the object either requires or creates a whole bunch of other dependencies. It is most likely out of your control what those dependencies are or do.

When your object is a simple dto it doesn’t suffer this problem and IoC is likely not so much required.