Utility of IoC and Dependency Injection

Question

There are some cases in which unit test don't work for the project.

I'm studing the Inversion of Control and Dependency Injection utilities and I would like to know if there are good reasons for use it than for make unit tests easier.

--update

Ok, let's analysis 1 of the cited advanteges: less coupling. You take out the coupling from the child type, and you add coupling to the handler type who need to create the objects to inject.

Without unit testing, what's the advantage in this coupling transfer (not coupling eliminate).

Answer 1

Sure, here are a few reasons:

1. Dynamic generation of proxies for remoting and transactons
2. Aspect oriented programming
3. Layering using interfaces and separation of implementation

Enough?

Answer 2

Yes, dependency injection helps you make your classes more focused, clearer*, and easier to change, because it makes it easier to adhere to the single-responsibility principle.

It also makes it easier to vary parts of your application independently of one another.

When you use constructor injection in particular, it's easier to tell what your code needs to do its job. If the WeatherUpdater class requires an IWeatherRepository in its constructor no one is surprised that it uses a database.

* Again, constructor injection only.

Answer 3

From the IoC wikipedia article:

• There is a decoupling of the execution of a certain task from implementation.
• Every system can focus on what it is designed for.
• Every system does not make assumptions about what other systems do or should do.
• Replacing systems will have no side effect on other systems.

While I would call the above feature list a bit vague, you see most of the above benefits, even without testing.

If I had to say it in a nutshell, I would say that IoC significantly improves separation of concerns which is a valuable goal in software development.

Answer 4

IOC/DI bring some very important features to your application

• Plugability: with DI you can inject dependency into the code without explicitly knowing how the functionality is actually working. For example: your class might get a ILog interface injected so that it can write logs. Since the class works with the ILog interface, it would be possible to implement a FileLog, MemoryLog or a DatabaseLog & inject this into your class. Any of these implementation will work fine as long as they implement the ILog interface
• Testability: With DI in your class, you can inject mock objects to test the behaviour of your class without actually needing the concrete implementation. For example: consider a Controller class which needs a Repository to perform data operations. In this case, the repository can be DI for the controller. If you need to write tests on the Controller class, you can pass a DI'd mock version of the repository without having to work with the actual repository class
• Configurability: Some of the common DI frameworks like Castle Windor, Unity, Spring etc., allow doing DI along with lifetime management of the object created. This is a very powerful feature & allow you to manage the dependencies & their lifetime via configuration. For example consider your application needs a ICache dependency. Via the configuration for lifetime & object management, you will be able to configure the cache to be a Per-application or per-session or per-request etc. without having to explicitly bake the implementation in your code.

HTH

Answer 5

IoC reduces coupling, which has a correlation with defect rates in some studies. (If that really long link doesn't work, it's to Software Engineering Quality Practices by Ronald Kirk Kandt.)