5

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:

  1. Is my observation correct that this implementation is the service locator pattern?
  2. If the answer to 1. is yes, then Do all IoC containers (like Autofac) use the service locator pattern?
  3. If the answer to 1. is no, then why is this differen?
  4. 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.

Improve this question
10
  • note Seeman's article you refer, seem to suggest Constructor Injection as an alternative to Service Locator (constructor injection to me looks like a better approach indeed, for the reasons laid out in that very article)
    – gnat
    Dec 11, 2012 at 9:32
  • As @gnat says, Constructor Injection is the alternative that Seemann seems to be recommending (although it would be easier to be certain if he just stuck to discussing the issue, rather than supercilious comments about "anti-patterns"). It doesn't make a huge difference, though: either way, if you don't configure your dependencies, you're going to get a runtime error. Ken Egozi's article shows constructor injection, by the way, via that Reflection code in IoC.Resolve()
    – Carson63000
    Dec 11, 2012 at 9:36
  • 1
    (as an aside, when I say Constructor Injection "doesn't make a huge difference", I mean it doesn't make a huge difference to the issues of causing run-time errors instead of compile-time errors, and making it unclear when you would be introducing a breaking change, as the article blames Service Locators for. It has various other benefits, such as ease of unit testing, and allowing flexibility as to whether a dependency is configured statically or resolved via a factory making decisions based on runtime variables)
    – Carson63000
    Dec 11, 2012 at 9:43
  • 1
    @TheSilverBullet well upon brief check it looks like service locator to me. As for "other approaches", the wikipedia link in my prior comment lists two approaches besides locator and DI - factory and lookup
    – gnat
    Dec 11, 2012 at 11:49
  • 2
    @TheSilverBullet, The service locator pattern is indeed used for the initial Resolve call. The service locator pattern has to be used at least once. Generally, the call is buried in some infrastructure detail, away from normal business class code. It will depend on how the application is structured to decide how the whole thing starts. But it indeed has to start with a call to Resolve first. In the framework I use, I define a custom factory class that is called at the start of each Http request, it then starts things with a call to Resolve. None of my business code knows about the container.
    – Kelly Ethridge
    Dec 12, 2012 at 21:37

2 Answers 2

Reset to default
9

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.

Improve this answer
0
1

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.

Improve this answer
1
  • I really wish I could accept both answers! Especially, my thanks for addressing all my questions.
    – TheSilverBullet
    Dec 17, 2012 at 8:39

Your Answer

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

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