When would you use the Common Service Locator?

Image 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 witch IoC container each of your callers will be using.

Image 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 witch IoC container each of your callers will be using.

The Common Service Locator let 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.

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. – Piotr Owsiak Sep 2 '10 at 16:10.

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.

With legacy code you may not be able to use constructor injection, property injection can be more appropriate then. – Piotr Owsiak Sep 2 '10 at 16:05 The Common Service Locator library is not just about the Service Locator pattern as I tried to explain in my answer. – Steven Sep 20 '10 at 11:45.

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 allows 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, taking a dependency on the CSL shouldn't be taking lightly. For 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 for 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 as all kind of validation support in it.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.