I often get asked what IoC Container I prefer. Short answer: StructureMap. I love the fluent syntax for configuration. Overall, it's easy to use, has many advanced features, and is very lightweight. I view the learning curve with StructureMap as relatively small. It is one of the longest-lived IoC containers (if not the longest) and has a huge adoption rate which means it's quite mature and not difficult to find code examples online. For example, there is the StructureMap mailing list. Additionally, the community is very proactive – I just sent an email question to Chad Myers today and got a response within minutes that solved my issue. The creator of StructureMap, Jeremy Miller, has one of the most useful blogs around (in addition to his column in MSDN magazine).
Despite all this, there are still several other very high quality IoC containers available including: Unity, Ninject, Windsor, Spring.NET, and AutoFac. Unity is Microsoft's offering in the IoC space and often it gets picked simply because it's got the "magical" Microsoft label on it. In fact, some organizations (for better or worse – usually worse) have policies against using OSS software and your only choice is to look at the offerings on the Microsoft platform. Despite this, Unity is actually pretty good but by P&P's own admission, there are instances where StuctureMap implementation is a little more elegant than Unity. But Unity does still have some compelling reasons to use it. In fact, if you are already using the Microsoft Enterprise Library Application Blocks, choosing Unity makes sense for a little more seamless experience.
Having said all this, there is one other major caveat to my preference towards StructureMap – it's the IoC tool I'm most familiar with. Therefore you should take a recommendation from me (or anyone) with a grain of salt. Ultimately the features of the various IoC's are going to be comparable and it's the developer familiarity with that tool that is going to make the difference. For folks new to IoC, most of the uses are going to be for simple constructor dependency injection and all the IoC frameworks can handle that easily. Given the wealth of quality IoC frameworks, we need another IoC framework about as bad as we need another data access technology. :)
