I am trying to get an understanding of Inversion of Control and the dos and donts of this. Of all the articles I read, there is one by Mark Seemann (which is widely linked to in SO) which strongly asks folks not to use the service locator pattern.
Then somewhere along the way, I came across this article by Ken where he helps us build our own IoC.
I noticed that is is nothing but an implementation of service locator pattern.
Questions:
- Is my observation correct that this implementation is the service locator pattern?
- If the answer to 1. is yes, then Do all IoC containers (like Autofac) use the service locator pattern?
- If the answer to 1. is no, then why is this differen?
- Is there any other pattern (other than DI) for inversion of control?
Consolidation of answers:
Answer 1. Kelly: The service locator pattern is indeed used for the initial Resolve call. The service locator pattern has to be used at least once.
Answer 2. Eric: Simply calling Ioc.Resolve(ISomeInterface) doesn’t mean that the IoC container is being used as a Service Locator. After all, Resolve() has to be called somewhere, right?
Answer 3. Tungano: No, his code contains a constructor receiving a dependency… No, a container doesn’t ‘use’ any pattern. It’s really up to the programmer using the container to use a pattern. It’s all in how you wire it together. Basically you can both use a container for DI and Service locator.
Answer 4. Gnat: …factory and lookup… [can be used for inversion of control.]
I have learnt, thanks to the above answers that IoC itself uses Service Locator Pattern. This is not inherently harmful. Using the IoC can be done in a number of ways (including the Service Locator Pattern). This is the part we need to take care and use other options of injecting the dependency.
10
Simply calling Ioc.Resolve(ISomeInterface) doesn’t mean that the IoC container is being used as a Service Locator. After all, Resolve() has to be called somewhere, right?
The clue is where and how many times is IoC.Resolve() is being called? If it’s being called all over the place, in the dependent objects themselves, then that’s a sign that the IoC container is being misused as a Service Locator. If Resolve() is being called in one central location (typically called the ‘composition root’), then it’s most likely being used correctly.
The article you mentioned doesn’t talk about when and where to call Resolve(), it just explains what happens after it’s called.
0
1) No, his code contains a constructor receiving a dependency:
public BuildDirectoryStructureService(IFileSystemAdapter fileSystemAdapter)
The IoC container is injecting the dependency.
If it used the service locator the BuildDirectoryStructureService would self obtain the dependency. For example:
public BuildDirectoryStructureService()
{
this.fileSystemAdapter = Locator.Current.Resolve<IFileSystemAdapter>();
}
An IoC container can be used as a service locator.
2 & 3)
No, a container doesn’t ‘use’ any pattern. It’s really up to the programmer using the container to use a pattern. It’s all in how you wire it together.
Basically you can both use a container for DI and Service locator.
4) You can do constructor injection and still not really have inversion of control. You can ask for concrete types in a constructor. Dependencies you inject may not have a workable abstraction for multiple implementations and such.
Inversion of control is aligned with the Hollywood principle, don’t call us, we’ll call you. Instead of operating a service you let the service “call back” on you over an interface it defines.
1