I am looking to implement an Inversion of Control (IoC) framework with my current client and thought I'd do some homework to make sure I use the best solution for the problem. I have prior experience with Spring.NET, Unity and Castle Windsor but have also been reading up on StructureMap and, most recently, Ninject.
My problem with the IoC "community" as it stands now is that I have to use a different framework for each UI technology. Spring.NET and Castle Windsor work great for standard BCL based applications like ASP.NET, Windows Forms, WCF and WPF but I previously had to go with Unity for Silverlight apps and none of these support mobile development with CF 3.5. That is what brought Ninject to my attention as it appears to support all of the .NET frameworks with the same tool.
So now my problem is making a decision. I don't have any experience with Ninject, it looks like it might be an immature framework and less used (especially compared to Spring.NET, Castle Windsor and Unity).
Without steering anyone in any direction, I thought this might be a good forum to simply ask what IoC framework(s) other devs are using and what successes or failures you've had. Let me know...
I've been using NInject lately, but have experience with Castle Windsor as well. I don't think you can go wrong with any of the options you mentioned, except that maybe NInject supports all the environments you want to use. If you use the Service Locator interface which I think all of the frameworks you mention support, then you don't have to take any hard dependencies and can switch your IoC if it doesn't meet your needs.
http://commonservicelocator.codeplex.com
HTH...
For those few times I have used IoC, I've been partial to StructureMap. No real technical reason. It was the first one I found (back before Unity was around), so I'm familiar with it. I'm not a huge fan of Unity simply because of the configuration verbosity required, but I hear that's much better in later versions (via their fluent interface). When I used StructureMap, I wasn't in situations where its trust limitations were an issue. I know that there were a lot of requests for a SL-compatible version of SM, and I believe that's high on his to-do list, if he hasn't done it already. It should work in all the other environments save for CF. I don't know whether he's planning on developing a CF-compatible version, and right now it sounds like he's taking a bit of an extended vacation (http://codebetter.com/blogs/jeremy.miller/archive/2010/08/12/i-m-taking-a-break-storyteller-and-structuremap-users-please-read.aspx).
I've not heard bad things about Ninject, and since it appears to be the only one that supports all your environments, that would seem to be the best solution. It certainly is not as widely used, and I don't know whether its still being actively developed or not. I understand the comment about putting the Common Service Locator interface in front, thus allowing you to pick-and-choose at your will. But honestly, I'm not a big fan of that concept. IoC frameworks are hard enough to conceptually get your head around, and while they all use the same basic concepts, they do them in different ways. Having to deal with multiple IoC frameworks, plus the CSL interface in front of all of them, seems like a bad recipe to me. And if you need something beyond what the CSL interface gives you...
HTH
- Scott
Yea, I've looked at the Common Service Locator project and have started down that path even before that but am on the fence with that regard. As I see it, to abstract the container, you have to code to the lowest common denominator which means you lose what makes each framework unique. For instance, I know Windsor has a nice fluent interface for configuration.
As a follow-up question to what framework you prefer, what is your opinion/stance on XML-based versus code-base configuration?
More and more I'm finding XML-based configuration to be more of a pain than it's worth, regardless of subject. I was lucky enough to discover StructureMap after the fluent interface was built. Add in the auto-scanning capabilities, and I was a happy camper. The XML-only option was, to be honest, my main problem with the initial release of Unity. I know they have a fluent interface now, so perhaps the friction isn't so bad.
IMHO XML is, and always will be, a very verbose way to describe data. Some people argue that the code-based configuration is just as bad - fluent interfaces are designed to read like English, after all - and the verbosity of XML-based configuration can be more easily overcome with tooling. This is a valid point, but I find the configuration tools MS puts out for their EL blocks to be... rather underwhelming. And AFAIK, all the other IoC tools are ditching their XML configuration for fluent interfaces.
Ultimately, code-based configuration allows me to not have to deal directly with XML, which is "a good thing" for me. I get enough angle brackets in XAML these days. 
If a decent UI could be built to allow me to set up my configuration, without having to directly mess with the XML, then I honestly wouldn't care one way or the other.
HTH
- Scott
I always use the code base configuration. Don't really like the XML based (too confusing / verbose). Regarding CSL, just wanted to make sure you were aware of the option, not really advocating its use in normal applications :) Even the wiki says:
"Should I use this library for my applications?
Typically, the answer to this question is no. Once you've decided on a container that suits your project, there's not a whole lot of benefit from writing your whole application in a way that can switch containers. For libraries that must fit into other ecosystems and play nicely with other libraries, it's an important feature, but for applications the extra layer of abstraction really doesn't buy you much."
Wrt CSL, I agree.
I get the feeling that neither of you are too concerned about post-deployment configuration changes? One of my concerns is using IoC to make the application extensible - meaning that I have multiple implementations that can be "plugged in" to customize the application's behavior. It has always seemed to me that XML configuration is the only way to accomplish this in a post-deployment scenario (iow, no recompilation). Am I wrong?
StructureMap's assembly scanner can scan all assemblies in a given path, so you should be able to create a plug-in path, drop your extension assemblies into that path, and have your app pick them up.
I can't speak to whether other IoC options have this capability, but I'm guessing others have something at least similar.
HTH
- Scott
yes, we use this feature of StructureMap and it works well. I haven't used any other IoC frameworks though, so I don't know if its better or worse than anything else.
Copyright (c) Marimer LLC