I've heard the term pop all around. I've read various articles regarding the subject and heard two main definitions to the term "Service Location":

  1. A glorified Registry - Bad practice, global variables, general evil.
  2. A type of Dependency Injection Container - Can help with managing dependencies, making modular and extensible applications, generally helpful.

But I can't differentiate between the two. What does a Service Location really means? Can you give a simple example of a Service Locator? Is it good or evil?


3 Answers 3


Those two things are essentially the same. A service locator is just any centralized system which lets you find a service to process some request. Using the service locator design pattern, you can use this to get an service implementation(which is really an interface at the code level) from the service locator.

More generally, this system is often used in distributed computing to find a node in the network which can service some other node's request.

For example, some client might want to perform some calculations on some data. Lets say there are multiple ways to do this calculation, each implemented as a service, but the client doesn't care which is actually used. The client could just ask for any service from the service locator, without having to worry which specific type is returned.

In both cases, the benefits and drawbacks are largely the same. The service locator lets you modularize your program better and lets you worry less about specific service implementations. On the other hand, you get this centralized point of failure that may be a weak link in your system. Like everything else, it's a tradeoff so there is no simple "good vs bad" answer.


The two definitions that you gave are for different things.

The first one (A glorified Registry) is actually called the Service Locator. It means that there is some entity (called the Service Locator) that other classes depend on to retrieve their dependencies at runtime. Take a look at this article for an example and for a reason why it is considered an anti-pattern.

The second one (DI containers) is not necessarily considered a service locator. It depends on where you are using it. If you are using it inside your classes to obtain dependencies, then it is used as a service locator. On the other hand, if you use it only in the Composition Root, then it is not used as a service locator. And many people consider using DI containers in the Composition Root a very good way to do Dependency Injection.


There are two key problems with a service locator/registry:

  1. Finding the registry. Often the only way is to have your code be explicitly told the location of the registry, though in some cases (DI containers, discovery protocols such as Jini) the discovery of the registry isn't so hard, or is even provided as a given.
  2. Ensuring that the information in the registry is correct/relevant. This is actually the hardest part of all. Even without the problem of malicious attacks, ensuring that any enduring collection of services is actually curated correctly is a horribly labor-intensive problem. (You can usually automatically detect when the information isn't right — with enough effort — but can't actually determine how to fix the situation without manual intervention.)

OTOH, it's entirely practical to replicate a distributed registry as long as the rate of change of the mappings it contains is not too fast. What do you think DNS is, if not a replicated registry? (Well, with extra stuff too.) This does suggest that using DNS to handle the hard parts of registry management might be a smart move, rather than replicating all that stuff again at a higher level of network stack…

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.