I am about to dip my toe into DI/IoC for the first time with part of an app we have in production. I've spent the last month or so researching DI/IoC and will most likely use the Castle Windsor Container although NInject may be an option.
Any of you folks out there got any advice & guidance on best practices, typical pinch/pain points, gotchas, anti-patterns.
A lot of DI tools make it really easy to use singletons which really are an antipattern - so the first pitfall to avoid is [excessive] use of singletons.
I'd highly recommend implementing an auto-registration strategy up front for two reasons:
I only have a tiny bit of experience with Spring, but a lot of work done with Guice. Of course those are Java tools, and this seems to be a very .NET oriented crowd so far. But the same concepts apply. I believe NINject is in the spirit of Guice.
If it's an existing code base, you're really going to be refactoring your code. In our case it was like untying a knot. You undo one dependency which frees up another one and you can refactor. You can just keep iterating until you've loosened up everything.
About singletons: You will have singletons. They are useful. The reason they are not as terrible with DI is that the classes which depend on them are not statically dependent on them. This keeps unit testing easy. Which (I think) is really the goal here.
I've recently been using the unity container and although I don't think it's quite as mature as Castle Windsor it seems to me to be very robust, have all the key features and as a bonus be more cohesively documented.
The selling point for me is that since it's from the patterns and practices team at Microsoft it was an easier sell in the corporate environment.
You're going to have fun retrofitting it into an existing solution though, i'd suggest you check out the DI podcasts on the alt.net podcast for some background on this as a possibility.
I've been using Castle Windsor with Binsor for a year or so now, and it's a joy to use! I highly recommend giving it a try.
+1 For castle windsor, however I would recommend using trunk as the 'official' release is quite old and there are many (some breaking) changes in trunk that will eventually get released.
I'd encourage you to be careful to not have references to your IoC/DI container anywhere except at the level where you register your dependencies and instantiate your Shell/Controller/Presenter/whatever and then let the dependencies flow from there. I've been tempted at times to call out to the static methods and get dependencies right there, but then, while attempting to remove dependencies and limit coupling, I'm now tightly coupled to my container!
I've also seen the practice of actually wrapping the IoC/DI container with your own facade so that you can swap out containers easily if you feel the need as is described here.
Thought I'd share a post from Jimmy Bogard on IoC container guidelines. He's got some good hints in there.