C# - Best practices for dependency injection in SDK projects?

Question

I'm working on this code base that, at a first glance, seemed to be doing dependency injection properly. However, doing some digging, I found that what's actually happening is that there's a Dictionary<IType, Type> being maintained in one of the classes, which allows devs to "register" the implementation type associated with an interface. Then, when a service is required, this class queries the dictionary for an existing instance, and if none, uses the Activator class to new one up (also inserting it into the dictionary for further reuse).

It's worth mentioning that this project is an SDK distributed via NuGet, and we cannot delegate DI resolve responsibility to end-users (would break the encapsulation principle, and besides, users can't be familiar with the intrinsic implementation details of each entity so as to be able to resolve the DI aspect on their end with whatever IoC container they're using).

All that said, my gut feeling tells me this isn't proper DI that I'm looking at here. I could be wrong, but it seems to me that this practice can lead to a number of different issues. Am I overthinking it?

I guess the real question would be, what are the best practices in terms of resolving DI specifically in a self-contained class library project distributed as an SDK?

Answer 1

Composition Root

Best practice is that everyone accepts their dependencies via constructor. This applies to classes in class libraries, console apps, api projects, or anything else (that accepts it, older frameworks don't work nicely with this).

Then, at the very top, whoever is actually running the code is responsible for resolving all the dependencies. Either manually or with the help of some DI container.

This allows code to have different dependencies based on runtime environment (i.e. Prod vs local, vs unit tests).

In your specific example, a self-contained class library project distributed as a NuGet package; the classes should accept their dependencies in the constructor and not worry about how they will be resolved.

There is a problem though, sometimes a project grows complex with dozens of dependencies and you don't want your consumer to have to resolve all of those especially if sensible defaults exist. In that case the library author may want to provide extra functionality to help resolve all those dependencies. You'll commonly see this in .NET applications in the form of builder.Services.AddProductName();.