title: Dependency Injection vs Service Location
body: <p>I am currently weighing up the advantages and disadvantages between DI and SL. However, I have found myself in the following catch 22 which implies that I should just use SL for everything, and only inject an IoC container into each class.</p>
  
  <p><strong>DI Catch 22:</strong></p>
  
  <p>Some dependencies, like Log4Net, simply do not suit DI. I call these meta-dependencies and feel they should be opaque to calling code. My justification being that if a simple class 'D' was originally implemented without logging, and then grows to require logging, then dependent classes 'A', 'B', and 'C' must now somehow obtain this dependency and pass it down from 'A' to 'D' (assuming 'A' composes 'B', 'B' composes 'C', and so on). We have now made significant code changes just because we require logging in one class.</p>
  
  <p>We therefore require an opaque mechanism for obtaining meta-dependencies. Two come to mind: Singleton and SL. The former has known limitations, primarily with regards to rigid scoping capabilities: at best a Singleton will use an Abstract Factory which is stored at application scope (ie. in a static variable). This allows some flexibility, but is not perfect.</p>
  
  <p>A better solution would be to inject an IoC container into such classes, and then use SL from within that class to resolve these meta-dependencies from the container.</p>
  
  <p>Hence catch 22: because the class is now being injected with an IoC container, then why not use it to resolve all other dependencies too?</p>
  
  <p>I would greatly appreciate your thoughts :)</p>