Do we need the Common Service Locator?
The Simple Service Locator has a hard dependency on the Common Service Locator. But is this a good design choice? I like to hear your opinion on this.
It's now been over a year ago since I published a first version of the Simple Service Locator project on CodeProject. The Simple Service Locator was (and still is) meant as an intermediate IoC framework, especially suited for developers that are new to IoC and are not yet familiar with any of the big (more complicated) IoC frameworks in the field. One of the core design goals behind the library was to make an IoC implementation that could easily be replaced it with a more feature-rich IoC framework when needed. Because of this I let the library have a hard dependency on the Common Service Locator.
It was not much later after releasing that first beta of the SSL that I started to doubt the usefulness of having a dependency on the Common Service Locator. The reason for it was that I (finally) started to see the benefits of writing applications in such a way that the dependency on a DI framework or an abstraction over it, could be removed altogether. By using the constructor injection DI pattern, instead of calling a container or an abstraction over it directly from code (which is known as the Service Locator (anti) pattern), we are able to almost completely hide the used IoC container from the application. Ideally there should be just a single line of code in the application that calls the container. Having a project structured like that, makes the need of using an abstraction redundant, because what's the use of an abstraction when you can replace it with one line of code?
I noticed that writing unit tests became much easier after I choose to use Dependency Injection over the Service Locator pattern. In the past I had a lot of nasty IoC configuration for my unit tests. I had to do clever tricks to make them run correctly in parallel (because MSTest runs tests in parallel).
The thing is however, that when you start writing unit tests for a code base that contains no tests yet, starting of with the Service Locator pattern is a hell of a lot easier than using the Dependency Injection pattern. When you start using dependency injection, you move the responsibility of wiring the dependencies together from a class up to its consumers. The consumers again will have to move the wiring to their consumers. In other words, when applying DI, it tends to have a ripple effect bottom up through your code base. To get an existing project structured like that, you probably need to refactor a lot.
Because of this I was (and still am) in doubt about whether forcing my users to have a dependency on the Common Service Locator is good thing, because a good designed application won't need it. On the other hand, because SSL is meant as an intermediate IoC framework, the library will probably be used as first IoC framework, and developers are likely to pick Service Locator over Dependency Injection.
Because of this doubt, I like to turn to you, my users of the Simple Service Locator, followers of the CodePlex project, and readers of my blog. If you are using SSL today, I like to know if you are benefitting from the Common Service Locator facade or if it's in your way. What are your thoughts about this subject? Do you think that having an hard dependency on the Common Service Locator is justifiable, or would the library benefit from being published without the Common Service Locator?
Please drop a note in the comments below or send me a mail (to steven at this domain) if you prefer that.
Thanks in advance.
Cheers
- .NET General, Simple Service Locator - ten comments / No trackbacks - § ¶
I think that the dependency on CSL has one advantage. It make simple to use SSL in conjunction with ASP.NET MVC 3.
But this can be done by mantaining the methods used to get and enumerate the services with the same name and signature that they already have.
Carlos Beppler - 01 03 11 - 23:22
So removing the CSL dependency would mean removing the Service Locator pattern entirely or just the CSL facade? I think the Service Locator pattern still has a place
Peter Miller - 02 03 11 - 15:00
I found Simple Service Locator by looking for a simple implementation of the Common Service Locator, in order to work with a framework that had a dependency on CSL. This was for a small project. As long as that kind of scenario is still easily supported even without the hard dependency, I don't see a reason against the change.
Chris W. Rea (URL) - 02 03 11 - 16:53
Peter,
My idea is to create a separate Common Service Locator adapter project for the Simple Service Locator (or perhaps even take a 'soft dependency' on the CSL if possible). You could then always use this adapter. Even without the Common Service Locator, the service locator pattern is easily created by storing the container in a static field that can be used throughout the application. For instance:
public static class ServiceLocator
{
public static SimpleServiceLocator Current { get; set; }
}
protected void Application_Start(object sender, EventArgs e)
{
// 1. Create a new Simple Service Locator container
var container; = new SimpleServiceLocator();
// 2. Configure the container
container.RegisterSingle(new Sword());
// 3. Register the container as service locator.
ServiceLocator.Current = container;
}
I hope this makes sense.
Steven (URL) - 02 03 11 - 17:27
I'm not a full-time or formally trained developer, but I do a fair amount of development for my job, and I'm willing to invest my personal time into learning best practices and applying them to my projects. When I discovered Simple Service Locator, I was in the process of building a project that made extensive use of constructor injection, and I was beginning to get bogged down in the tedium of wiring everything up. So, I decided it was finally time to try out an IoC framework, and, with a few minor modifications by Steven, Simple Service Locator fit the bill perfectly. So, I'm definitely no expert on the subject, but I will say that having to reference a separate assembly and read up on why it was there did me slow me down a little at the beginning. And after that, I did have to ask myself a couple times whether I needed to reference both assemblies or just Simple Service Locator. None of that was a big deal, but the experience would have been a little more streamlined if I didn't have to worry about this extra dependency.
Regarding your statement that "Ideally there should be just a single line of code in the application that calls the container," I wasn't able to quite get down to just one line, but I can say that all my calls to ServiceLocator.Current.GetInstance() are contained in my App.xaml.cs file (the app in question is built in WPF).
Dan M - 04 03 11 - 03:27
As noted by Peter Miller, I believe the Service Locator still has its place and that as a first step it is definitely easier to adopt that a complete DI solution.
Your plan sounds execlellent as it still allows people to easily use the service locator without it being embedded in by default. In separating it from the core it also allows you to document the pros/cons of using the Service Locator Pattern that people newer to the technology might not know.
Either way good luck.
Scott MacLellan - 06 03 11 - 19:32
Thanks for all the comments. They are really useful.
Steven (URL) - 13 03 11 - 13:50
Yes! I must confess that I'm not a user of SSL or haven't even looked at it. But it's really lovely that you got support for CommonServiceLocator. But if I were you, I would provide two installation packages: One with CSL ilmerged into the assembly and one that you haven't ilmerged.
Now I'm going to try to solve the math puzzle you got.... (1 hour later) .. yay! solved. it.
jgauffin (URL) - 25 05 11 - 21:04
Hi J. Gauffin,
Thanks for the response. I actually decided something similar to your advice. I left Simple Service Locator as it is with CSL included, and I created a new version, which I call Simple Injector. The Simple Injector does not have the CSL included, but contains an adapter project for it. I'm actively maintaining the Simple Injector now.
Steven - 25 05 11 - 23:08
I was beginning to get bogged down in the tedium of wiring everything up. So, I decided it was finally time to try out an IoC framework, and, with a few minor modifications by Steven, Simple Service Locator fit the bill perfectly.
Thanks,
http://www.cocoresolutions.com
Sabrina Clough (URL) - 27 10 12 - 10:54