When is using IoC appropriate?

Question

I understand what IoC containers are and have been reading up on Structure Map. The technology seems easy enough to use. My question is, what is the appropriate level of granularity for using an IoC container?

I see the following possible levels of application for IoC:

1. Break every dependency between all objects - certainly overkill.
2. Break dependencies between all major objects such as domain objects, support classes, and components within subsystems.
3. Use IoC in conjunction with a Facade to wrap a subsystem (such as logging) with a public interface and then break the dependency on that interface.

I know the answer to this question is "it depends", but from your experience, what does then answer depend on? Is project size a factor?

Furthermore, where doesn't IoC make sense to use?

Answer 1

I think it makes sense to use it when you know you will be writing a lot of unit tests as it makes the construction of those tests easier. Also, it allows you (via external configuration) to change the behavior of objects during runtime.

It doesn't make sense to use IoC on smaller projects or projects that don't need massive decoupling.

Answer 2

I'd say it makes the most sense when you either know you'll need a flexible application because requirements will be changing often, or when you will be working on a large system with a team of developers. It helps when working on a team because you can work on your piece and let IoC take care of your dependencies.

Answer 3

One scenario for IOC is when a specific implementation decision is contested among the development team. IOC gives the the flexibility of being able to swap out implementations with minimal friction. This is more of a tactical consideration than anything.

Answer 4

Well, IOC doesn't make a lot of sense if you're programming a very concrete component that will not have multiple types of implementations...

For example; say you are programming a document reader for your company and you know for a fact that the business rule behind the reader is that it will never read any other document type then an MS Word document. In this case, your unit tests do not really require loose coupling of dependency injection because the component that you are testing will never be dependent on anything other then an MS Word document. It may just be overkill to use an IOC container to resolve the reader type.

Answer 5

The idea isn't to break dependencies between domain objects, it's to shield your domain from the outside world. Your domain objects should be about whatever business problem you are solving and not about databases, logging, caching, http contexts, rest services etc...

This article talks about moving responsibilities out of your objects and into the IoC container.

http://www.agileatwork.com/captcha-and-inversion-of-control/