I’m not afraid to say it… I’m still trying to wrap my head around DI/IoC. There, I said it! I mean I get it but I am not sure I really "GET” it, know what I mean? (Note to Self: And I probably won't until I start coding with it, so start coding with it dummy! ;) (You can tell it's a Friday and I start talking to myself and calling myself a dummy... lol)
- The problem – tight coupling
- Principles of IOC
- Ways of implementing IOC
- Implementing the DI
- What’s wrong with DI FACTORY?
- The container way
- Implementation using Windsor
- Other Interview question PDF's
In this section we will discuss about how IOC and DI can help us build loosely coupled software architecture. I am not sure should we call this a design pattern or more of a approach. If you search around the web you will see lot of controversy on whether IOC is a design pattern or not. From my point of view it is a design pattern as it solves a problem context.
It would be great to see actual architectures implementing IOC using container oriented approaches. I am sure it will change the way we think about interaction between components.
So let’s understand in detail about IOC and DI.
And I'd bet there's a silent developer majority our there who might be in the same boat as me. We've heard about it, seen few casts, read a few articles, but have yet to actually jump in...
The above Code Project has a few translation issues, but I liked it. I thought it presented one of the problems DI/IoC is trying to solve well and did a good job (with pictures! ;) explaining why DI/IoC is a good solution. The code samples, using Castle Windsor, are also easy to follow and understand.
This article will not be your only stop on the groking DI/IoC, but it's work a quick pitstop...