I'm still working my way through my backlog of unread posts in Google Reader (not even halfway through it :s) and one thing i noticed by reading some posts is that we (.NET developers) generally seem to be pretty loyal when it comes to which IOC container we use. Some of us might switch between different containers from time to time, but i get the feeling that most of us typically stick with the container that we've come to know the best.
Some people will stick with Castle Windsor, some swear by StructureMap, some will always use Autofac, some only want NInject... hell, i even know a few people who still prefer Spring.NET. The only one that doesn't seem to have many loyal followers is Unity
. Every container has its strengths and weaknesses but most of them range from very good to downright excellent. When new features are introduced to one container, they often quickly find their way into the other containers as well. A cool new feature in container X is rarely a good incentive to switch containers because odds are high that your favorite container will get the new feature pretty soon as well.
What i think is a big reason of this (observed) loyalty is that the more you rely on your IOC container's power, the less likely you are to switch to another container out of fear that some things might behave differently or might not work the way you think or expect they will. If the container you've chosen to use has proved itself to you in production usage, you are very unlikely to replace it with another. After all, it's a very important piece of how your project works and you probably depend on it a lot. You've probably become very familiar with its behavior in different circumstances and you've either come to rely on that, or have learned to live with it in some way. But you've learned how it works and you're pretty sure that there are no unpleasant surprises that will pop up a couple of days or weeks after a new deploy. Because of that, i really wouldn't feel all that comfortable with switching to a new container. And lets face it, they all have their little special cases that you really need to know about to avoid problems.
And if you are using features that are unique to your container, then you're obviously even more unlikely to make a switch. In my case, i used Castle Windsor when i first started to use an IOC container. I ran into some issues with memory usage because of the way Windsor works, but once i learned that i always have to explicitly release any resolved components, the problems went away. In fact, i've come to rely on the fact that by releasing a resolved component, its disposable transient dependencies will automatically be disposed by Windsor as well. I'm not sure about this, but i think Windsor is the only container that does this, or at least one of the few that do. I actually consider it a must-have feature for a container, but most people don't seem to consider this as important.
I can't really imagine a situation that would make me consider switching to another container at this point... well, unless its development would someday halt obviously. And even then i'd probably be holding on to it for a long while. How about you? How likely are you to switch to a different container? And what would make you switch? What holds you back from switching to a different one? Which one do you use and why do you like it so much?
Pingback: A Nuget Packaging Dilemma