title: Dependency injection and Libraries/Frameworks
body: <p>OK, maybe here is such question already, but I didn't find it..</p>
  
  <h2>The problem</h2>
  
  <p>We have big enterprise application with a lot of entry points. App contains part like:</p>
  
  <ul>
  <li>Server</li>
  <li>Desktop Client</li>
  <li>Some console utilities</li>
  <li>.NET API (separate assembly, with root class called like <code>MyAppAPI</code>)</li>
  <li>COM API (the same, separate assembly, you can access to API from, for example VBScript, by <code>Set api = CreateObject("MyApp.MyAppAPI")</code></li>
  <li>Java API (again, the same)</li>
  <li>Messaging API (separate assembly, used for communicating between layers through messages queues)</li>
  </ul>
  
  <p>We use Unity as DI container in this app. Everything is cool in Server/DesktopClient/Console utilities etc. - there are very concrete entry points, so we just initialize <a href="http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx" rel="nofollow">composition root</a> object there, initialize tree of objects/dependencies, and everything works like a charm. Them problem is with our APIs.</p>
  
  <h3>#1</h3>
  
  <p>How to deal with DI in libraries/frameworks?</p>
  
  <p>From the link above:</p>
  
  <blockquote>
    <p>The Composition Root is an application infrastructure component.</p>
    
    <p>Only applications should have Composition Roots. Libraries and
    frameworks shouldn’t.</p>
  </blockquote>
  
  <p>Yeah, it's cool, but.. I want to use DI in my API, it's huge! How to deal one with other?</p>
  
  <h3>#2</h3>
  
  <p>We have dependencies, which preferably should be singletons (e.g. some factories, which control lifetime of created objects). But, we can create some instances of API objects, how to share this singleton instances between them? Even more - we can create some instances of .NET API objects and one/some instances of COM API objects in the same domain (if you want, I can explain in the comment when it's possible)..</p>
  
  <h2>What I have now</h2>
  
  <p>As I said, there is no problem with apps, the problem exists in libraries (APIs). So, what I have now</p>
  
  <ul>
  <li>I have class <code>ShellBase</code></li>
  <li>this class contains static field <code>_Shells</code> and public static methods <code>Get</code> and <code>Release</code></li>
  <li>there is hierarchy between containers (e.g. APIs' containers are inherited from MessagingAPI, Server and DesktopClient containers are inherited from .NET API container etc.)</li>
  <li>when somebody ask for new shell (through <code>Get</code> method), <code>ShellBase</code> checks if there is already such container (or super-container, from subclass), and returns that instance. Or creates new one</li>
  </ul>
  
  <p>I don't like this way, but this is the best what I can imagine right now.</p>
  
  <h2>Possible solution</h2>
  
  <p>Create something like <code>APIFactory</code>, which will create our API objects, but it looks.. too complicated for end-users. I don't want to write in user documentation: "Please, create and keep APIFactory instance first, then you can create API instances using this factory". It's ugly. Our users should write just <code>var api = new API()</code>, and use it.</p>
  
  <p>So, guys, what do you think?</p>