Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Microsoft P&P is building a new IoC/DI tool — and I’m okay with that

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:



  1. 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.

  2. 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. 

  3. 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.

  4. 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.”

  5. 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.

  6. 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?

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in DI, IOC. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • JST Books

    Specialist personal injury claims solicitors are the best people to represent you in such actions. They are aware of court procedures in personal injury claims litigation, and will often try to resolve the reason for the PIAB authorisation letter before your case ever reaches court especially if the PIAB authorisation letter has been issued due to a dispute over how much personal injury compensation you should receive.

  • http://davidhayden.com/blog/dave/ David Hayden

    Basically – It’s not the actual provider model in the .NET Framework, but a provider-based approach to providing services.

    I think we need to just wait and see. Enterprise Library will be much more excellent when we get OB out of there, and a powerful combination of the DIAB and the PIAB ( Policy Injection Application Block providing AOP services ) will be very useful. I just hope they put in an additional lightweight interception mechanism into the PIAB.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @David,

    So, we’re going to use an extremely poor implementation of IoC (the Provider model) to switch out the underlying IoC tool. Still ironic and kinda funny. Not that I’m complaining.

  • http://davidhayden.com/blog/dave/ David Hayden

    Jeff, Jeremy-

    The Application Blocks in Enterprise Library are provider-based. So, they are probably providing a base abstract provider class that serves as the API and creating one implementation that provides dependency injection services ( think of membership and role services in the .NET Framework and the provider model ).

    Others can then come along and create other implementations that use other dependency injection tools.

    I am guessing, of course, but this would be consistent with the other application blocks.

  • stefan.moser

    The problem is that too many people are going to think that DIAB is the Lucky Charms. We use NHibernate and a lot of developers on my team have recently been saying that they can’t wait to sub it out for the Entity Framework. Then I need to go into my long-winded speach about Persistence Ignorance. Argh!!

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Jeff,

    Yes, yes it does. We’re going to swap out the engines on the fly that allow you to swap out services on the fly.

  • http://www.jeffperrin.com Jeff Perrin

    “you can swap out the base implementation for StructureMap, Windsor, or Spring.Net”

    Does that not strike anyone else as being funny?

  • http://www.ayende.com/Blog/ Ayende Rahien

    > Doesn’t Dependency Injection Application Block sound a lot like a generic cereal to you?

    LOL