The Common Service Locator library
The CommonServiceLocator project was released this week on CodePlex with the general idea of providing an IoC container agnostic API for resolving dependencies using Service Location. Erich Eichinger from SpringSource contributed the Spring.NET implementation, thanks Erich!
Here is the API so you get the basic idea
object GetInstance(Type serviceType);
object GetInstance(Type serviceType, string key);
IEnumerable<object> GetAllInstances(Type serviceType);
TService GetInstance<TService>();
TService GetInstance<TService>(string key);
IEnumerable<TService> GetAllInstances<TService>();
}
One of the fears I had in participating in this project was that it would promote the approach of Service Location/Dependency Pull over Dependency Injection. I’m glad to see blogs entries like Ayende’s and (more forcefully) Daniel Cuzzulino’s that put this library in the proper perspective.
The intention of this library is primarily for low-level integration between application frameworks. It has a role in business code only as a last resort when you need to ask a container to provide you with a new object instance at runtime that takes advantage of additional container services such as configuration via dependency injection or applying AOP advice. WebForms, WCF Services, and ‘traditional’ server-side objects created at application startup (DAOs, etc) can all be configured non-invasively using dependency injection.
If you find yourself frequently using the service locator approach in your application you should consider refactoring the code to use dependency injection. Not only will you remove an extraneous dependency, always a good thing, but you will get the additional benefit of making your class easier to unit test in isolation of the container as its dependencies will be exposed via standard properties and constructors.
One alternative approach, used in Spring Java but not yet implemented in Spring.NET is to provide a ServiceLocatorFactoryObject, described by my colleague Alef Arendsen here. This allows you to write your own simple service locator interface, for example.
Process CreateProcess(string processId);
}
The container would provide the implementation dynamically at runtime. You can then use dependency injection to configure your class with a reference to ProcessCreator. The only service locator 'API' provided with ServiceLocatorFactoryObject are of methods with the signatures IMyService GetService() or IMyService GetService(string id) but others could be envisioned.
Similar Posts
- Spring .NET 1.1 and container configuration
- Method Injection
- Spring Dependency Injection & Java 5 (including slides and code)
- Setter injection versus constructor injection and the use of @Required
- So what's the deal with Spring-OSGi?
Joe Schmoe says:
Added on October 3rd, 2008 at 2:45 pmIts Apache Avalon^H^H^H^H^H^H^H^H^H Common Service Locator!
Mark Pollack (blog author) says:
Added on October 3rd, 2008 at 2:46 pmYup, as Arjen Poutsma said, "Service Locator is so 90's"
André says:
Added on October 22nd, 2008 at 10:50 amI've recently read an article on InfoQ from 2006 about Spring.NET where you talked about a book that you where publishing.
Can you name the title of the book or the ISBN ?
Thanks.
Mark Pollack (blog author) says:
Added on October 22nd, 2008 at 3:33 pmAt that time we did sign a book deal and basically never found the time to write it. We are right now in the process of renegotiating/reviving that contract and hope to have a book out by summer next year.
Szymon Pobiega says:
Added on June 8th, 2009 at 1:40 amHi
I am a huge fan of the idea of Common Service Locator since Jeremy's initial blog post. Finally I was able to write really reusable components. I found it most useful in code libraries where one cannot make assumptions on which DI container his users will use.
One thing I was missing in CSL was ability to register new mappings in the container. Such function would be very useful when designing factory objects where the factory class creates a child container for its exclusive use and then registers mappings for classes it produces.
My friend Piotr and I decided to extent CSL with such function. We called our project MetaContainer and published it on codeplex. MetaContainer is built on top of CSL.
I write this e-mail to ask you to help us develop adapters for particular containers. We managed to write three of them (due to out limited knowledge and resources). Because MetaContainer is only an extension to CSL, writing an adapter wouldn't be difficult is one knew particular container very well.
There is one additional issue: CLS project seems to be a little abandoned. During development on MetaContainer we found several problems which should be addressed either on conceptual level or implementation level (like scope of mapping name: can be type-scoped or global-scoped). These problems are also relevant to CSL and should be solved to allow seemles use.