In case you haven’t already seen the announcement or Ayende’s denouncement, the Patterns and Practices team is going to build a new Dependency Injection Application Block as part of the next wave of the Enterprise Library. As the primary builder of one of the Open Source IoC/DI tools you’d expect me to be indignant about this, but I’m not. I was certainly peeved about ObjectBuilder a couple years ago, but this time is different. Partially it’s because I’ve always assumed that they’d get around to this at some point, so it’s not any great shock. I’m not particularly upset because of a couple reasons:
- The P&P team reached out to me for input on their new DI tooling. I also know that they’re talking to some of the other teams as well. I still think the P&P guys could have, and should have, done this with ObjectBuilder.
- They said the magic words: we’re going to make it pluggable so you can swap out the base implementation for StructureMap, Windsor, or Spring.Net. That’s a huge acknowledgement of the success of these tools from the P&P team. Exactly what we’ve been waiting for from these guys for a long time.
- They might build something better or at least innovative. There’s absolutely no doubt in my mind that I could build a better StructureMap from scratch today after 4 years of actually using IoC tools. They get to start at the end of that experience curve. Of course, if mainstream developers start to use IronRuby, IoC rapidly loses its relevance, but let’s not get side tracked here.
- All of us consultants sooner or later get forced to work for a company with a strict no OSS policy. Since I really don’t care to write an IoC tool from scratch (and I really don’t care for ObjectBuilder), it’s nice to have something usable from MS itself that I can sneak in. Of course, in reality I’d just download the StructureMap source code and replace “StructureMap” with “NameOfCompany.IoC.”
- I think Enterprise Library could be a lot more usable if they really embrace Dependency Injection throughout. There are pieces of EntLib that I think would be useful, but I don’t want to bring in all the dependencies or wrestle with the Xml configuration. Using DI for configuration generally means that your classes are less coupled to some sort of underlying Xml configuration. I think applying Inversion of Control to configuration (I don’t go get my application settings myself, somebody else will do that for me in my constructor) will make the EntLib easier to digest.
- The newer P&P framework and factory thingies can be built with IoC/DI from the ground up. If we’re going to restrict ourselves to static typed languages for the time being, I want enterprise systems and frameworks built with IoC. Even more importantly, I can use the tool of my choice that I’m already familiar with for configuration of my services. That’s a big win.
CodePlex notwithstanding, Microsoft’s poor attitude and relationship to Open Source Software efforts on the .Net platform has had a negative impact on the community at large. That out of the way, let’s give P&P a chance here. They did come out and ask for involvement from us. We’ve been whining that they don’t include us or take feedback early on. Here’s our chance. Instead of throwing rocks at them, let’s try to participate in a helpful manner. Maybe we can set Microsoft and us up to avoid more Entity Framework debacles.
As for the competition angle between StructureMap/Windsor/Spring.Net and DIAB, think of the branding. Calling anything the Something Application Block and putting it next to the original OSS tools is a lot like putting the cheap knockoff cereal boxes right next to Lucky Charms in the grocery store. Doesn’t Dependency Injection Application Block sound a lot like a generic cereal to you?
