There is this article that says:
A Composition Root is a (preferably) unique location in an application where modules are composed together.
Only applications should have Composition Roots. Libraries and frameworks shouldn't.
A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container.
My question is like this:
We have a Console app and in another project a library that performs some algorithm. It has a class
AlgorithmFactory, which takes an
AlgorithmInput as a parameters and creates an
AlgorithmRunner. Facts are:
- From the console I want to call:
AlgorithmInputcontains run-time data that some library classes need for their configuration (for example:
RoundingPrecisionindicating the number of decimal places that we should round to, or
ConnectionString, or some other types of credentials...)
AlgorithmInputalso contains data that indicate which implementation of a particular interface should be used (for example: there is an interface
ISorter, and two implementations:
RadixSorter. There are classes which depend on
ISorterand don't care which one is used, this information will be part of the input)
AlgorithmRunnerinternally depends on a non-trivial number of classes. Its complexity suggests it acts as a separate sub-application.
I can't really configure the algorithm outside of the library, because I need run-time data for it. But I'm not supposed to reference the container from the library (or any other component). How is this scenario usually solved? (I believe it must be a well-known case).