The Dependency Injection Application Block from Patterns and Practices

In case you’ve missed it, Grigori Melnik has announced that the forthcoming version of the EntLib will include a new application block for Dependency Injection.  I know there’s been some level of disquiet about this announcement in ALT.NETish circles, but I think it’s going to be a good thing.  I wrote a little bit about it before, but the key points for me are this:

  • Used well, Dependency Injection can do a lot of good in creating a modular design (and no, having TypeMock does not entirely replace the need for or value of DI).  Hopefully, more developers will be introduced to the concepts and usage of DI and Inversion of Control by the new DIAB.
  • From Gigori:  “…we plan to refactor individual EntLib blocks and abstract away configuration code (configurators).“  Jeremy’s take:  EntLib classes will now be usable without having to muck with the configuration Xml.  I don’t use EntLib in some small part due to my perception of it being “coding in Xml.”
  • Patterns and Practices is reaching out to the OSS teams that have already built successful, working Inversion of Control containers.  I think that will alleviate some of the griping about ObjectBuilder from certain folks (like me).  Yes, it’s another de facto competitor to working OSS tools from Microsoft, but at least they’re being much more open and cooperative this time around.
  • You will be able to swap out the new DIAB for an existing IoC container like StructureMap in both the EntLib and the new WPF Composite client guidance/framework.  That’s a huge deal in my book.  Just like the new MVC framework, the new WPF Composite client won’t force a choice of IoC tool upon you.

Frankly, I don’t see anything to get all that upset about.  All of us StructureMap/Windsor/Spring.Net enthusiasts need to remember that there are unenlightened shops that simply won’t use any OSS tools — and Microsoft choosing to promote any one of the existing IoC tools as the one true path would start a geeky civil war.

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.
  • paweł paul

    Great work! you need informations about This is the kind of information that should be shared across the net. Disgrace on the seek engines for now not positioning this put up higher! Come on over and seek advice from my website . Thanks =) Many, many thanks! forex exchange trading basics

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

    @Matt,

    A couple points:

    * The crucial difference is that classes that get everything through the constructors are completely decoupled from any configuration. Think about that. Once the EntLib is really “bootstrappable” through constructor functions you’ll be able to more easily slice off little bits and pieces of the EntLib and reuse those classes without any Xml whatsoever or some entirely different form of configuration. It’s what I think of as “push” configuration versus “pull” configuration. It’s very valuable to decouple code that provides services from its configuration. It’s easier to write tests and much, much easier to reuse code. All of my configuration is done with StructureMap, but if you threw away StructureMap you’d still be able to use all of my classes.

    http://structuremap.sourceforge.net/ConfigurationManagement.htm

    * I don’t know about Spring, but StructureMap and Windsor both have purely programmatic API’s for configuration to avoid Xml almost altogether. Actually, that’s the way that I’d recommend going. Less chance for screwing up and less junk to deploy.

  • http://sticklebackplastic.com Matt Ellis

    Hi Jeremy. I’m just wondering what you see the difference in EntLib’s “coding in xml” and all the xml required to define a DI container?

    (I’m not trolling, just trying to understand why DI is such a hot topic)

    Cheers
    Matt

  • http://jroller.com/Solomon Solomon Duskis

    InfoQ has picked up on this story… I added this entry to the comment list. I’m sure that your comments would be extremely relevant there…

    http://www.infoq.com/news/2007/12/entlib4_dependencyinjection

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

    Holy crap. Grigori was an instructor of mine, and my first boss as a software developer. I had no idea he was at Microsoft until I read this post. Dude is a manic Russian genius.

  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo

    This makes a lot of sense for organization who are not allowed to take advantage of OSS tool sets. Now they have a best practice approach that is actually a best practice and the support of MS.

    Win win for everyone.

  • http://activeengine.wordpress.com ActiveEngine Sensei

    The strength of ALT.Net is that it has extended the boundaries of the solution toolkit, whereas if you stick with the standard MSDN issue of solutions you can get locked into your own toolkit. If it’s not on MSDN, it’s not worth looking into. In the end this will limit your mastery of development skills as you won’t be forced to examine why you are doing things, and how those things are directly or indirectly related to other disciplines.

    Yes it is cool that Microsoft if giving a nodd to ALT.Net. It may open the floodgates for other innovations.

  • http://bigjimindc.blogspot.com/ BigJimInDC

    Having just failed in the fight to promote ALT.NET concepts on my current team, primarily due to arguments that what I was promoting just “wasn’t what Microsoft was promoting” and therefore there aren’t enough devs “out there” that we could hire to support it, I’m all for Microsoft promoting these things, in hopes that the fight I just lost just might be the last. From the likes of folks like Haack getting hired there, hopefully this is the beginning of a trend there to “legitimize” ALT.NET concepts to the uninitiated.