in Search

Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

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

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?

Published Jan 16 2008, 03:50 PM by Jeremy D. Miller

Comments

Haacked said:

We could call it ObjectFactoryFactory. ;)

# January 16, 2008 4:12 PM

Haacked said:

We could call it ObjectFactoryFactory. ;)

# January 16, 2008 4:12 PM

Ayende Rahien said:

Jeremy, there is already one there:

IServiceProvider, now we just need a way to register that globally.

# January 16, 2008 4:32 PM

Jeremy D. Miller said:

Ayende,

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

Resolve<T>()

Resolve<T>(key)

and maybe

IEnumerable<T> ResolveAll<T>()

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

# January 16, 2008 4:37 PM

Haacked said:

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?

# January 16, 2008 4:53 PM

Jeremy D. Miller said:

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.

# January 16, 2008 4:58 PM

Ayende Rahien said:

IDependencyResolver

# January 16, 2008 5:06 PM

Sean Feldman said:

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?

# January 16, 2008 6:07 PM

Jeremy D. Miller said:

@Sean,

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

# January 16, 2008 6:11 PM

David M. Kean said:

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)?

# January 16, 2008 9:52 PM

Jeremy D. Miller said:

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

# January 16, 2008 11:28 PM

Haacked said:

Ok, how about IDynomite!

public interface IAwesomenessIncarnate : IServiceLocator

{

T GetService<T>(string key);

T GetService<T>();

}

# January 17, 2008 2:11 AM

Jeremy D. Miller said:

IBuildStuffSoThatYouDontHaveTo

# January 17, 2008 2:46 AM

Derek Greer said:

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.

# January 17, 2008 9:30 PM

Javier Lozano said:

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

interface IServiceLocator : IServiceProvider

{

T GetService<T>(string key);

T GetService<T>();

}

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:

www.castleproject.org/.../index.html

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

# January 18, 2008 10:21 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Jeremy D. Miller

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 previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#.

Our Sponsors

Proudly Partnered With

This Blog

Home
Contact

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

Jeremy D. Miller -- The Shade Tree Developer

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

Comments

Haacked said:

Haacked said:

Ayende Rahien said:

Jeremy D. Miller said:

Haacked said:

Jeremy D. Miller said:

Ayende Rahien said:

Sean Feldman said:

Jeremy D. Miller said:

David M. Kean said:

Jeremy D. Miller said:

Haacked said:

Jeremy D. Miller said:

Derek Greer said:

Javier Lozano said:

Leave a Comment

About Jeremy D. Miller

Our Sponsors

Proudly Partnered With

This Blog

Syndication

Recent Posts

Tags

News

Blogs I Read

Archives