Service locator - worth it?

Question

We have a large solution (> 100 projects) and almost every type uses either a service locator (example 1) or our own dictionary of types (example 2) for instantiation.

For example we have:

IQuote quote = Registry.Resolve<IQuote>(); 

or

IQuote quote = Registry.Find<IQuote>(args);

The 2nd example goes off to the config file to find what concrete object to instantiate using reflection.

It makes life more difficult when following through code - because it's not clear what concrete type is being used - so we have to check the mappings many times as we're trying to learn a part of the code. Using the above as an example pressing F12 on: quote.DoSomething() would take you to the interface definition.

It's also a bit more difficult to implement - we need an interface + concrete class + config mappings, when the alternative is just 1 class.

Come to think of it - I'm not aware that anything has ever been "swapped out" for another type - so although we've implemented IoC we haven't used it, or at least - very little.

So - is it actually worth it? Have we implemented it incorrectly / too much? Am I misunderstanding something?

Answer 1

What you guys are using is a Service Locator that is being considered an anti pattern, because of:

1. All Unit Tests have to use the Service Locator (with DI no DI Container is involved)
2. You couple your whole architecture to the Service Locator (in DI only the Composition Root is using the DI Container)
3. You can not see the dependencies immediately of a component (with DI there is Constructor Injection)
4. Your Unit Tests become more complicated, because you have to care of your configuration, so that no other test uses another configuration erroneously (Tear Down).

http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

Answer 2

In my opinion, you don't need to work with each and every class with DI in mind. I would use the following strategy:

1. Determine the module bounds.
2. Within the same module, use concrete classes where possible.
3. For the intermodule communication, use DI where possible.

The modules should be relatively fine-grained.

There are some common places where you need to use DI, often it's replaceable data sources and (not so often) algorithms. Use the common sense to check whether something needs to be replaceable or not. Don't hesitate to throw in an early refactoring if you see something needs DI or suffers from it.

Answer 3

What you show is NOT a dependency injection, it is a configurable registry (which is also a pattern, but quite different). So yes, looks like a bad idea and a sort of misunderstanding.

To be able to reap benefits of some design pattern, you have to understand the benefits up-front. If you don't know them, then probably you shouldn't bother.