When would you use the Common Service Locator?

Question

I've been looking at the Common Service Locator as a way of abstracting my IoC container but I've been noticing that some people are strongly against this type of this.

Do people recommend never using it? Always using it? or sometimes using it? If sometimes, then in what situations would you use it and what situations would you not use it.

Kasandrakasevich

Are you looking for usage scenarios for Common Service Locator specifically or more generally for the service locator pattern? The terms are not necessarily interchangeable... – Ocker

Answer 1

Imagine you are writing library code to be used by 3rd party developers. Your code needs to be able to create service objects that these developers provide. However you don’t know which IoC container each of your callers will be using.

The Common Service Locator lets you cope with the above without forcing a given IoC on your users.

Within your library itself you may wish to register your own classes in the IoC, now it gets a lot harder as you need to choose a IoC for your own use that will not get in the way of your callers.

Neutrality

I would only add that you may be forced to use CSL also when you simply do not have a common Composition Root or it is outside of your control. An example would be a custom certificate validator in WCF service. – Rostand

Answer 2

I noticed that one of the arguments against using the CSL is a false one because developers think this library is only capable of doing the Service Locator pattern. This however isn't the case, because it is easy to use it with the Dependency Injection pattern as well.

However, the CSL library was specially designed for framework designers who need to allow users to register dependencies. Because the library will be calling the CSL directly, from the framework's perspective we're talking about the SL pattern, hence its name.

As a framework designer, however, setting a dependency on the CSL shouldn't be taken lightly. For the usability of your framework, it is normally much better to have your own DI mechanism. A very common mechanism is to set up dependencies in the configuration file. This pattern is used throughout the whole .NET framework. Almost every dependency can be replaced by another. The .NET provider pattern is built on top of this.

When you, as a framework designer, take a dependency on the CSL, it will be harder for users to use your application. Users will have to configure an IoC container and hook it up to the CSL. However, it is not possible for the framework to validate the configuration as can be done while using the .NET configuration system, which has all kinds of validation support in it.

Sephira

Answer 3

I've done some reading on the service locator concept lately. It is a way of helping to reduce coupling, but requires code coupling to the locator - not the container backing the locator, but the locator itself. It is a tradeoff, but can be beneficial in the right situation.

One situation where it can be helpful is when you have code that does not make use of DI, such as legacy code - I am in this boat now. Pulling in required objects via SL, rather than directly creating them, allows the addition of some abstraction. I see it as an intermediate step between SL and DI/IoC.

Termless

With legacy code you may not be able to use constructor injection, property injection can be more appropriate then. – Rostand

The Common Service Locator library is not just about the Service Locator pattern as I tried to explain in my answer. – Sephira

Answer 4

If you have library code that is in need of services and this code could be hosted in the context of a larger framework/runtime then the framework / runtime would need to provide a mechanism where you can run some custom code on startup wherein you can initialize your container and register dependencies. A good example of where CSL can be problematic is when using it in the context of MSCRM. You can have custom business logic executed by registering plugins which the MSCRM framework executes on certain events. The problem you run into is where do you run the registration logic since there is no "startup" event that you can subscribe to for setting up your DI container. Even if you could somehow setup your DI you would need to put the CSL and the DI libraries in the GAC since that is the only way to call out to 3rd party code from a plugin (one more item to add to your deployment checklist). In scenarios such as this you are better off having your dependencies as constructor parameters that the calling code can initialize as it sees fit( via either constructor injection or manually "newing" up the appropriate interface implementation).

Karb