title: Dependency Inject (DI) "friendly" library
body: <p>I'm pondering the design of a C# library, that will have several different high level functions. Of course, those high-level functions will be implemented using the <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod" rel="noreferrer">SOLID</a> class design principles as much as possible. As such, there will probably be classes intended for consumers to use directly on a regular basis, and "support classes" that are dependencies of those more common "end user" classes.</p>
  
  <p>The question is, what is the best way to design the library so it is:</p>
  
  <ul>
  <li>DI Agnostic - Although adding basic "support" for one or two of the common DI libraries (StructureMap, Ninject, etc) seems reasonable, I want consumers to be able to use the library with any DI framework.</li>
  <li>Non-DI usable - If a consumer of the library is using no DI, the library should still be as easy to use as possible, reducing the amount of work a user has to do to create all these "unimportant" dependencies just to get to the "real" classes they want to use.</li>
  </ul>
  
  <p>My current thinking is to provide a few "DI registration modules" for the common DI libraries (e.g a StructureMap registry, a Ninject module), and a set or Factory classes that are non-DI and contain the coupling to those few factories.</p>
  
  <p>Thoughts?</p>