title: Abstracting IoC Container Behind a Singleton - Doing it wrong?
body: <p>Generally, I like to keep an application completely ignorant of the IoC container.  However I have ran into problems where I needed to access it.  To abstract away the pain I use a basic Singleton.  Before you run for the hills or pull out the shotgun, let me go over my solution.  Basically, the IoC singleton does absolutly nothing, it simply delegates to an internal interface that must be passed in.  I've found this makes working with the Singleton less painful.</p>
  
  <p>Below is the IoC wrapper:</p>
  
  <pre><code>public static class IoC
      {
          private static IDependencyResolver inner;
  
          public static void InitWith(IDependencyResolver container)
          {
              inner = container;
          }
  
          /// &lt;exception cref="InvalidOperationException"&gt;Container has not been initialized.   Please supply an instance if IWindsorContainer.&lt;/exception&gt;
          public static T Resolve&lt;T&gt;()
          {
              if ( inner == null)
                  throw new InvalidOperationException("Container has not been initialized.  Please supply an instance if IWindsorContainer.");
  
              return inner.Resolve&lt;T&gt;();
          }
  
          public static T[] ResolveAll&lt;T&gt;()
          {
              return inner.ResolveAll&lt;T&gt;();
          }
      }
  </code></pre>
  
  <p>IDependencyResolver:</p>
  
  <pre><code>public interface IDependencyResolver
      {
          T Resolve&lt;T&gt;();
          T[] ResolveAll&lt;T&gt;();
      }
  </code></pre>
  
  <p>I've had great success so far with the few times I've used it (maybe once every few projects, I really prefer not having to use this at all) as I can inject anything I want: Castle, a Stub, fakes, etc.</p>
  
  <p>Is this a slippery road?  Am I going to run into potential issues down the road? </p>