Designing a Nuget Package with Dependency Injection

Question

We are currently writing a nuget package that acts as a service gateway. Its responsibility is to wrap up the call to an external service, so that is made in the correct way and the response is dealt with correctly. Its aim is to reduce the dev time overhead when a new client wants to consume the external service.

The nuget package is built from a single project, called 'client', in the solution of the external service. This is so the client project can share a common domain and also keep build numbers in sync for when it is published. The client project applies the inversion of control principle, meaning that the class acting as the entry point (the start of the stack to get a response from the external service) has a number of interface dependencies.

We usually use StrucutreMap as our IoC container, but I am wondering how we configure our client project with dependency injection 'built-in'? It seems wrong that every consumer should have to wire up dependency resolution for the package. However, it also shouldn't be the case that every client should use StructureMap and have to add the 'ClientRegistry' (initializer) class to its own start-up logic.

Are there any guiding principles to help solve this problem? Or any good examples of complex nuget packages that are built on the IoC principle?

Answer 1

You could use CommonServiceLocator - it's not quite as rich as a full IoC container but it will make your package container agnostic, and should allow consumers of your package to continue using the IoC container of their choice.

The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.