title: Is ServiceLocator an anti-pattern?
body: <p>Recently I've read <a href="http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/" rel="noreferrer">Mark Seemann's article</a> about Service Locator anti-pattern.</p>
  <p>Author points out two main reasons why ServiceLocator is an anti-pattern:</p>
  <ol>
  <li><p><strong>API usage issue</strong> (which I'm perfectly fine with)<br />
  When class employs a Service locator it is very hard to see its dependencies as, in most cases, class has only one PARAMETERLESS constructor.
  In contrast with ServiceLocator, DI approach explicitly exposes dependencies via constructor's  parameters so dependencies are easily seen in IntelliSense.</p>
  </li>
  <li><p><strong>Maintenance issue</strong> (which puzzles me)<br />
  Consider the following expample</p>
  </li>
  </ol>
  <p>We have a class <em>'MyType'</em> which employs a Service locator approach:</p>
  
  <pre class="lang-cs prettyprint-override"><code>public class MyType
  {
      public void MyMethod()
      {
          var dep1 = Locator.Resolve&lt;IDep1&gt;();
          dep1.DoSomething();
      }
  }
  </code></pre>
  <p>Now we want to add another dependency to class 'MyType'</p>
  <pre class="lang-cs prettyprint-override"><code>public class MyType
  {
      public void MyMethod()
      {
          var dep1 = Locator.Resolve&lt;IDep1&gt;();
          dep1.DoSomething();
              
          // new dependency
          var dep2 = Locator.Resolve&lt;IDep2&gt;();
          dep2.DoSomething();
      }
  }
  </code></pre>
  <p>And here is where my misunderstanding starts. The author says:</p>
  <blockquote>
  <p>It becomes a lot harder to tell whether you are introducing a breaking change or not. You need to understand the entire application in which the Service Locator is being used, and the compiler is not going to help you.</p>
  </blockquote>
  <p>But wait a second, if we were using DI approach, we would introduce a dependency with another parameter in constructor (in case of constructor injection). And the problem will be still there. If we may forget to setup ServiceLocator, then we may forget to add a new mapping in our IoC container and DI approach would have the same run-time problem.</p>
  <p>Also, author mentioned about unit test difficulties. But, won't we have issues with DI approach? Won't we need to update all tests which were instantiating that class? We will update them to pass a new mocked dependency just to make our test compilable. And I don't see any benefits from that update and time spending.</p>
  <p>I'm not trying to defend Service Locator approach. But this misunderstanding makes me think that I'm losing something very important. Could somebody dispel my doubts?</p>
  <p><strong>UPDATE (SUMMARY):</strong></p>
  <p>The answer for my question &quot;Is Service Locator an anti-pattern&quot; really depends upon the circumstances. And I definitely wouldn't suggest to cross it out from your tool list. It might become very handy when you start dealing with legacy code. If you're lucky enough to be at the very beginning of your project then the DI approach might be a better choice as it has some advantages over Service Locator.</p>
  <p>And here are main differences which convinced me to not use Service Locator for my new projects:</p>
  <ul>
  <li>Most obvious and important: Service Locator hides class dependencies</li>
  <li>If you are utilizing some IoC container it will likely scan all constructor at startup to validate all dependencies and give you immediate feedback on missing mappings (or wrong configuration); this is not possible if you're using your IoC container as Service Locator</li>
  </ul>
  <p>For details read excellent answers which are given below.</p>