The Common Service Locator library

Glenn and Chris has already gotten the word out, but that is an important piece of news.

The idea is based off a post that Jeremy Miller had about a month ago, having a common, shared interface across several IoC implementation. That would allow library authors to make use of the benefits of a container without taking a dependency on a particular implementation.

The alternative for that is to each library to create its own abstraction layer. A good example of that is NServiceBus' IBuilder interface, or ASP.NET MVC's IControllerFactory. That is just annoying, especially if you are integrating more than a single such framework.

This project was created with the aid of most of the IoC containers authors on the .NET framework, and we have adapters for Windsor, Unity, Spring.NET already, with adapters for the rest of the containers coming soon.

What it is not?

It is not meant to be a complete container abstraction. The reason that the interface is so small (and you wouldn't believe the amount of time that it took to settle on exactly what is going to be there) is that this is not supposed to be the container that you are using. This is explicitly designed to be a read only interface that allows a library to use the container, not some uber container interface (which doesn't really make sense considering the differences between the containers).

Why Service Locator vs. Container? Again, the design is focused on enabling integration scenarios, more than anything else.

I still recommend to avoid explicit service locator usage whenever possible, and to rely on the container and dependency injection. This is not always possible, which is what this library is supposed to solve.

Who should use this?

If you are releasing a piece of code that is taking a dependency on a container, you should consider that as an option. It is generally considered to be a better idea than to force your choice of containers on the clients. The OAuth library for .NET is going to move to this, for exactly this reason.

I am from Microsoft, can I use this?

The code is released under the MS-PL, and all of the work on the project was done by Microsoft employees. That was quite intentional, since this is allow Microsoft projects to make use of that (this is Microsoft IP). If you are a Microsoft employee, you can make use of that. In fact, according to Chris, the next version of the Enterprise Library is going to use this as the container abstraction, so you'll be able to use the Enterprise Library with Windsor and StructureMap and Spring.NET and Ninkect and AutoFac and all the rest of the things that I forgot.

I can use only Microsoft products, can I use this?

See previous question.

Where can I find the code

The codeplex site is here: http://www.codeplex.com/CommonServiceLocator

Print | posted on Thursday, October 02, 2008 9:49 PM

Feedback


Gravatar

# re: The Common Service Locator library 10/2/2008 10:30 PM chrissie1

Cool.


Gravatar

# re: The Common Service Locator library 10/2/2008 10:45 PM Lucas Goodwin

I remember when this was being bantied about a while back as an idea. I'm impressed it turned into reality. Good job everyone who worked on it.


Gravatar

# re: The Common Service Locator library 10/2/2008 11:03 PM hammett

It is not intended as a replacement for specific factories.


Gravatar

# re: The Common Service Locator library 10/2/2008 11:07 PM Ayende Rahien

That is my own use case for this


Gravatar

# re: The Common Service Locator library 10/2/2008 11:08 PM Jimmy Zimms

While it is for-suck, hopefully the abstraction is a strongly typed extension to IServiceProvider from mscorlib. It's the lowest common demoniator in .net for service locators.

L'Shana Tova!


Gravatar

# re: The Common Service Locator library 10/2/2008 11:09 PM hammett

Could be yours, but it's not mine, nor we have consensus that this is a good idea.

So please don't mix the message of the goals, which should be clear on the codeplex page.


Gravatar

# re: The Common Service Locator library 10/2/2008 11:33 PM Louis

Very cool. No release/dispose?

Looks like IServiceProvider is baked in there.

www.codeplex.com/.../FileView.aspx

And a static ServiceLocator.Current with a delegated implementation. Excellent.

www.codeplex.com/.../FileView.aspx


Gravatar

# re: The Common Service Locator library 10/2/2008 11:36 PM Ayende Rahien

Hammett,
From my first email in the subject:
"We need some sort of a common way to refer to a container that isn't tied to a specific implementation. This is important in all the situations where you are writing a library that should make use of a container but not a particular one."


Gravatar

# re: The Common Service Locator library 10/2/2008 11:38 PM Ayende Rahien

From CodePlex's site:
"The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation."


Gravatar

# re: The Common Service Locator library 10/2/2008 11:42 PM hammett

That's different from saying that people wont need to implement Factories anymore. Factories carry semantics, a well defined contract. The Service Locator wont always match up.

Starting off with the fact that a factory is suppose to create things - always - whilst the service locator is to locate (maybe create) things.


Gravatar

# re: The Common Service Locator library 10/2/2008 11:47 PM Neil Mosafi

Interesting, I actually created my own IServiceLocator interface in a project a while ago to allow my factory classes to locate classes to provide to consumers. It only had one method - Resolve() which delegated to the castle container. With the locator registered in the container, the factory classes could declare a constructor dependency on the IServiceLocator and have them passed in.

Nice work!


Gravatar

# re: The Common Service Locator library 10/2/2008 11:47 PM Ayende Rahien

I don't think that we can agree on that, because I don't think that a factory has to create a new instance. In fact, since most of the time, the factories that I am thinking about looks like this:
IFoo Create(string param);
I see no reason to add unnecessary level of abstraction just to be pattern complete.


Gravatar

# re: The Common Service Locator library 10/2/2008 11:48 PM hammett

I'm not looking for agreement. I'm just saying that your use case isn't necessarily the one on the project.


Gravatar

# re: The Common Service Locator library 10/3/2008 12:56 AM Chris Tavares

And this, ladies and gentlemen, is why it took two months to write an interface with 6 methods on it. I feel like I just earned a degree in cat herding. ;-)


Gravatar

# re: The Common Service Locator library 10/3/2008 1:08 AM tasarım

It is great. Thanks for your efforts


Gravatar

# re: The Common Service Locator library 10/3/2008 9:16 AM Andrey Shchekin

Good job. I was going to create a container abstraction as a part of net-ioc-frameworks (http://code.google.com/p/net-ioc-frameworks/), now I can do the locator part in a most interoperable way.

The only thing that I really dislike is seeing a class with 'Impl' in its name. What's up with .NET use-full-words policy?


Gravatar

# re: The Common Service Locator library 10/3/2008 5:18 PM Will Shaver

There's a big discussion regarding this topic on the MVC google groups.

groups.google.com/.../b86881b920cba0b4

The problem being how to handle things that implement IDisposable, and how to know when to release them.


Gravatar

# re: The Common Service Locator library 10/3/2008 6:52 PM Chris Tavares

@Andrey: Yeah, the name of that class is ugly. The choice of name was actually deliberate on my part - I wanted to make it abundantly clear that it was only a convenience for implementation of the interface, and NOT something that people should be referring to otherwise.

Did it succeed in that goal?


Gravatar

# re: The Common Service Locator library 10/4/2008 12:04 AM Andrey Shchekin

Sure. I would have said that 'Base' is enough, but I see your point.

However, what about ServiceLocatorImplementationBase? It is long enough so no one sane will use it as reference (having interface), and it is not breaking .NET guidelines.


Gravatar

# re: The Common Service Locator library 10/17/2008 2:36 AM Turkey

great an article, I'm very thank you, I think really usefull, I'm following comments, thanks

Comments have been closed on this topic.