+972 52-548-6969
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 Ninject 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
Comments
Cool.
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.
It is not intended as a replacement for specific factories.
That is my own use case for this
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!
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.
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
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."
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."
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.
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 <t() 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!
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.
I'm not looking for agreement. I'm just saying that your use case isn't necessarily the one on the project.
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. ;-)
It is great. Thanks for your efforts
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?
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.
@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?
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.
great an article, I'm very thank you, I think really usefull, I'm following comments, thanks
Comment preview