IoC Container Applicability / Scenario Demonstration?

Question

A lot of people in the .NET space have picked up Castle Windsor and are implementing it in their projects, and for the past year I've been struggling to figure out why IoC containers seem to be treated as general "best practice"? I've read a LOT of abstracts and brief explanations on the why's of Windsor and the like, but every last one of them are indeed abstract and don't seem to be practical for most projects I have touched, yet lately I've been coming across a lot of projects that use Windsor and I don't understand why.

C#/.NET inherently supports interface-based coding, abstract objects, delegates, and events. One can implement IoC right from the core language and, using Reflection and the like, instantiate unknown instances that implement known interfaces, without resorting to IoC container libraries.

When applying the YAGNI/AYGNI (Are You Going To Need It?) I feel like Windsor has been over-used. I can certainly see the benefits of an IoC container but I feel that these benefits come at the cost of additional dependencies and metadata (IoC container specific attributes and methods called in core code, .config files scattered everywhere, app.config/web.config filled up with binding tags making the .config file more difficult to edit, etc) so I'm trying to figure out the trade-off.

That said, I'm accepting the possibility that I'm making ALL of these observations / statements on ignorance since I've never been heavily involved with a project that used Windsor or other IoC container library. What I really need is for someone to demonstrate an "average" or "typical" project where an IoC container library was used and why this is supposed to be a "best practice" when to me it seems like it makes an otherwise clean project messy with dependencies and metadata.

If anyone knows of any blog posts, articles, or books that would fill me in, that'd be awesome.

(I'm not arguing for arguing sake, but because I really do want to be educated as to whether I should educate myself on IoC containers).

Answer 1

Seems like you want the answer to this question

Obviously if the system is as difficult to setup as you say, then its not going to be worth much when you come to maintaining it. That's a significant thing to bear in mind when using a new technology. Sometimes the old boring stuff is way better because of just this factor.

Castle Windsor uses reflection itself, so its really a wrapper to doing things the way you want anyway. If you can develop a system that is simpler to use than CW then you should, even if it costs you in initial startup time. That cost will be offset by the learning curve of CW in the first place, so it won't be quite like reinventing the wheel.

They do say themselves that IoC is not suitable for small projects,

Also, depending on the size and complexity of the project, an IoC container might be overkill. Prefer to use it on medium to large projects.

Answer 2

It is not a direct answer to your question because I'm not familiar with castle-windsor, and I'm not an IoC expert, but from my experience with the java version of Spring I can tell that (I'm talking about Spring here, so it may not be the case with castle-windsor) it is not just the dependency injection part which makes it great, but also the framework itself: declarative transaction management, built-in security framework, ORM support, built-in MVC web framework, RMI, Web services, Email, AOP, etc. And it all kind of nicely integrates with the IoC, and the fraework really does a lot of work for you for most typical scenarios.

And autowiring with annotations + IDE support (e.g. IntelliJ IDEA for Spring) I think alleviates the configuration file problem.

I don't know if castle-windsor is anything besides IoC container, but if it is, maybe it is just not there yet in terms of the richness of its functionality as a framework.

Answer 3

I don't necessarily believe that an IoC container is good in all cases. But it definitely can be. If you use dependency injection or service locator for handling dependencies you've come a long way anyway, but a IoC-container can help with doing things automatically, give you support for more advanced scenarios, etc.

I tried to define it for myself in a blog post a good while ago:

An Inversion of Control (IoC) Container is a non-invasive configurable intelligent factory-component

Splitting this definition in parts, we get

• Factory, because it is responsible for creating objects for you.

• Intelligent, because it understands what dependencies you have, and create them for you recursively.

• Configurable, because you can configure the usage through code or configuration files.

• Non-invasive, because the objects used doesn’t need to know about the container.

  -

If you use it properly with the dependency injection or service locator pattern you do get some really handy benefits. You don't necessarily need to use an external container like Winsor, but that does give you some additional benefits.

You can write far less code instantiating new objects. And if you think of more complex object hierarchies, an IoC container can help create the entire chain for you automatically. That can be very powerful.

You can easily add mocked versions of the objects during testing without problems (if you use DI and/or SL). For instance creating a service locator for yourself would solve this as well though.

Changing the dependencies you want to inject in the constructor doesn't necessarily mean you need to refactor much code.

You get various benefits of tunneling dependencies through one source: Decorators, Interceptors, Proxies, as well as handling object lifestyle. With a container like Windsor, this enables you to do some hard things really simple, with extremely little coupling

You can leviate its concept of facilities for smooth integration with for instance NHibernate

Answer 4

I suggest that you listen to episode 2 of the Software Engineering Radio podcast. It is a whole episode on dependency injection. Dependency Injection is the most widely known usage of Inversion of Control frameworks. I would also recommend listening to DotNetRocks episode 362 which has John Kovacs. Here is a transcript of the show.

Now a side effect of IOC is increased testability. The usage of IOC container like Castle Windsor aids in decoupling dependencies. This decoupling makes for better unit test.

Most IOC frameworks also come with ways of facilitating Aspect-Oriented Programming. So if you are into that IOC container frameworks can help you with that.