When It Comes To IOC Containers, We Seem To Be Pretty Loyal

11 commentsWritten on February 15th, 2010 by
Categories: Inversion Of Control

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?

  • Darren

    Actually, I’ve seen a pretty loyal following behind Unity — myself being part of it. I started with Unity, it was easy to get it through allowed for production use in my company, and I haven’t seen any reason to change.

    In fact, I’m not sure I could change to a different IoC and retain the same functionality. Now, I haven’t looked at the others lately and I know I’ll get hit as soon as I say this, but months ago I didn’t see the some features that I use in Unity (Interception, child containers, etc.) in the others.

    As we’ve matured in our use of IoC, though, container choice has become a non-issue because we hardly see the container. We only touch it directly in the few cases where we need to apply an exception to our convention-based registration, or when we use things like interception. Otherwise, we’ll keep the resolution of classes hidden away behind the Common Service Locator.

  • flukus

    I think it’s because the containers just stay out of the way, an amazing feat for such an integral part of our products.

    We use autofac at the moment and it just sits there quietly doing it’s job. I could completely replace it in an afternoon but see no compelling reason to do so.

  • Matt

    FYI, Autofac will automatically handle releasing components on your behalf unless you explicitly tell it not to – one of the many reasons we chose to adopt it instead of Windsor.

  • http://www.agilification.com Jeff Doolittle

    StructureMap is my IoC Container flavor of choice. I love the simplicity of its default conventions. I lve the terseness of the configuration DSL (and it gets more terse all the time). I have also used Unity and Ninject, but have come back to SM every time. I’ve considered looking into Windsor, but I haven’t found a desperate need for it and SM continues to add new features every couple of weeks that typically help me go faster with less friction.

    I think you’re right about the loyalty assessment. I definitely feel that pull to think my IoC tool is the “best” but I’d definitely like to hear more from others about what their container can do that mine can’t. I’ve noticed that if enough conversations like these occur, that the project maintainers tend to add such features (like Func dependency resolution – stolen from AutoFac and just added to SM last week!).

    –Jeff

  • Jason Meckley

    I’m loyal to Castle. That came about because I decided to learn Rhino.Tools. Rhino relies heavily on Windsor so it forced me to learn Windsor as well. If I were to switch I would move to SM, but I have no need to at this point.

  • http://simon-says-architecture.com/ Szymon Pobiega

    I stick to Unity simply because Unity makes simple things and concepts simple. For me, the lack of fluent interface and all these bells and whistles StructureMap has is a huge advantage: I can take a novice programmer and teach her both inversion of control theory and practice in just a few hours. Without her knowing about fluent interfaces.

    And last one: usage (and often over-usage) of sophisticated container features could be a sign of building application that depends on DI infrastructure. And even if I don’t use my container API _explicitly_, if I rely on features like automatic disposal, there is an implicit dependency.

  • http://davybrion.com Davy Brion

    @Szymon

    there’s definitely an implicit dependency on that kind of behavior, yes

    But i’ll take that over having my components knowing about the lifecycles of their dependencies and whether or not they can or need to be disposed. They really shouldn’t have to know about it, and because of this behavior in Windsor, they don’t have to.

  • http://kozmic.pl Krzysztof Koźmic

    @Szymon,

    Take Ruby on Rails crowd – they took implicit relying on features of their framework and turned it into an art. It’s hardly a bad thing if it lets you crank the code faster.

    @Darren – I don’t think there’s _any_ container that does not support interception or child containers. Unity is hardly the source of innovation in IoC space, unless you consider laying GUI on top of IoC configuration an innovation.

    Now to the real question.
    On my previous project I used Unity and I hated it (http://kozmic.pl/archive/2008/12/03/unity-framework-and-the-principle-of-the-least-surprise.aspx).

    Currently I use AutoFac (hey Nick) and while I miss certain features of my favorite container (especially in terms of integration with NHibernate and WCF) it pretty much works as expected and does the job, so there’s no bad thing I could say about it.

    When I’m in charge I usually use (surprise) Windsor, which I just know very well, it is _very_ extensible and can be easily customized and tweaked for needs of my application.

  • http://sneal.net Shawn Neal

    I started out with Spring.NET, and hated all the explicit XML configuration, but it was easy to learn for a Java programmer.

    Found Castle Windsor and used that for a few years until about a year ago when I switched to AutoFac.

    Autofac has good support for nested/child containers and the ability to automatically release all dependencies which I find very handy for managing units of work. Autofac is also faster at object construction (from what I’ve read http://www.clariusconsulting.net/blogs/kzu/archive/2009/04/17/141951.aspx).

  • http://www.agilification.com Jeff Doolittle

    @Kryzysztof – “they took implicit relying on features of their framework and turned it into an art. It’s hardly a bad thing if it lets you crank the code faster.”

    Amen.

  • Pingback: A Nuget Packaging Dilemma