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:
IoC.AlgorithmFactory.CreateAlgorithmRunner(input).Run()
AlgorithmInput
contains run-time data that some library classes need for their configuration (for example:RoundingPrecision
indicating the number of decimal places that we should round to, orConnectionString
, or some other types of credentials...)AlgorithmInput
also contains data that indicate which implementation of a particular interface should be used (for example: there is an interfaceISorter
, and two implementations:MergeSorter
,RadixSorter
. There are classes which depend onISorter
and don't care which one is used, this information will be part of the input)AlgorithmRunner
internally 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).