Our team had recently a big struggle of deciding whether it is a good practice or not for the .NET Core class libraries to register their own implementations by the fact of providing a IServiceCollection extension methods like AddMyServices().
My point was that it is good to do this because:
- Top level application does not need to know all the details of the underlying library it is going to use,
- Top level application (usually Startup class) is not polluted with references to all the namespaces required to register its implementation.
- If top level application wants to provide its own custom implementation of some interfaces defined in the referenced library, it still can do it. .NET Core dependency injection allows multiple registrations.
- If there is more applications referencing this class library, you would not need to copy paste a block of e.g. AddTransient lines to each application.
Counterarguments were that:
- Some example applications use the approach of registering all the implementations in the top level Startup method.
- The above approach is only used for features (but it creates semantic doubts around what can be called a feature and what not). Still class library can name features it implements and provide separate AddFeatureXYZ() methods in the IServiceCollection extension class.
- Using AddService() extension method which registers all the implementations it may provide, may impact the performance of DI container, which makes sense in case where certain class library provide many impementations but only few are used. But a developer still have a freedom of calling AddServices() or not.
I wanted to ask about it more experienced .NET Core developers about their approaches with all the pros, which maybe I am missing. If there are any strong arguments for using the second approach I didn't list here, I would really love to get acquainted with it.
PS. This question was moved from StackOverflow as it was marked as more opinion based. In my opinion it is touching the core priciples of object oriented programming, and the question is not to find out what majority of developers is choosing, but about why somebody favours one approach against the other.