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 SOLID 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.
The question is, what is the best way to design the library so it is:
- 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.
- 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.
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.
Thoughts?
