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).
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.