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