Is it time to make IoC/DI tooling part of the BCL?

Posted by Jeremy Miller on January 16, 2008

 I’m in Redmond this week helping out Patterns and Practices with a focus group on the WPF Composite guidance that is going to be the successor to the CAB.  Modular development is on everybody’s mind here, and the de facto solution for stitching all of the components together is some sort of IoC/DI tooling.  Great, but one of the gripes about CAB is that it forces you to use the ObjectBuilder and many people want to use their own container.  P&P is on the ball, so they’re planning to have some sort of way to swap out the IoC container.  Great, but… 

  • The MVC framework guys are making the container swappable (and one of the highlights of my career was hearing ScottGu say “you could use StructureMap” out loud in the MVC unveiling).
  • I saw a slide about Acropolis that had a block that said “Dependency Injection.”
  • WCF arguably has a service locator built into itself.
  • The Provider Model is effectively an implementation of Service Locator

It might be a good idea to finally put a very generic hook in the CLR Base Class Library to register an IoC container so that all these different pieces can start using a consistent IoC mechanism.  I’m pretty sure I’ve heard or read Microsofties say that they’re considering it.  I think I’m ready to vote for it.  What do you think?

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 Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://blog.lozanotek.com Javier Lozano

    I’ve extended the IServiceProvider before to add my generic extensions

    interface IServiceLocator : IServiceProvider
    {

    T GetService(string key);

    T GetService();
    }

    and that works pretty well since some APIs use the IServiceProvider interface, so I can just pass my derivative. Have you seen the WCF integration facility for Windsor? It’s pretty sweet:
    http://www.castleproject.org/container/facilities/trunk/wcf/index.html

    Why can’t they do something like that? Or is it that their way of handling external dependencies too “baked in”?

  • http://ctrl-shift-b.blogspot.com Derek Greer

    Having missed the Acropolis wave, I just heard about its DI approach in the focus group. I really liked the description of their DI container as an “object factory pipeline” which is really what I see ObjectBuilder as, and why I think I like it so much. While Object Builder was explicitly called out as a “factory for building DI containers” and not a container in and of itself, it really is more abstract than that.

    If Microsoft were to provide an interface with some out-of-the-box implementation that could be switched out for performing IoC, I would rather its interface be more factory based than Service Locator based.

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

    IBuildStuffSoThatYouDontHaveTo

  • http://haacked.com/ Haacked

    Ok, how about IDynomite!

    public interface IAwesomenessIncarnate : IServiceLocator
    {
    T GetService(string key);
    T GetService    ();
    }

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

    @David,

    I’d vote for IServiceLocator myself, but some people now seem to think its passé to name a class with a pattern name that it implements.

  • http://blogs.msdn.com/fxcop David M. Kean

    There is also IServiceContainer (and it’s default implementation ServiceContainer) which can be used for registering/retrieving services. With regards to the new name for a generic equivalent, how about IServiceLocator (this is what I’ve used in the past for my own personal IoC framework)?

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

    @Sean,

    It’d probably help if we’d ask first;)

  • http://weblogs.asp.net/sfeldman Sean Feldman

    That would make it consistent and a norm de facto.
    How realistic for this to be implemented? The idea is great, but will be BCL team willing to go with it?

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

    IDependencyResolver

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

    No, no, no! I don’t ever wanna see IHTMLElement, IHTMLElement2, IHTMLElement3, IHTMLElement# ever again.

    I’m with Phil on this one about a whole new interface.

  • http://haacked.com/ Haacked

    IServiceProvider unfortunately has an incompatible API for the one that Jeremy wants. It looks like:

    object GetService(Type serviceType);

    That’s baked into an interface, so you’re stuck there. We could add IServiceProvider2, but I think a new name would be better.

    IObjectProvider?
    IServiceResolver?

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

    Ayende,

    Yeah, but I think we want the common facade to at least support:

    Resolve()
    Resolve    (key)

    and maybe

    IEnumerable ResolveAll()

    I agree with you though. If it’s just something like the way we register IPrincipal, I think we’d have it.

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

    Jeremy, there is already one there:
    IServiceProvider, now we just need a way to register that globally.

  • http://haacked.com/ Haacked

    We could call it ObjectFactoryFactory. 😉