¿Cómo gestionas la configuración con inyección de dependencia?

Soy un gran admirador de DI / IOC. Es excelente para manejar / abstraer dependencias difíciles, y hace la vida un poco más fácil.

Sin embargo, tengo una pequeña queja, que no estoy seguro de cómo resolver.

La idea básica en DI / IOC es que cuando se crea una instancia de un objeto, todas sus dependencias se rellenan previamente dentro del constructor.

Sin embargo, en mi humilde opinión, hay varios tipos de parámetros para los constructores (especialmente cuando sus objetos son inmutables).

1. Dependencias (objetos necesarios para que su objeto funcione)
2. Configuración (información sobre el entorno requerido para hacer el trabajo)
3. Parámetros (datos en los que se trabaja)

Me parece que el COI funciona bien con las dependencias. Pero todavía estoy tratando de encontrar la mejor manera de lidiar con los otros dos. Sin embargo, dado que el constructor está ejecutado para ser ejecutado por el contenedor IOC, parece que necesito colocar estos elementos en el contenedor IOC.

Me gustaría saber qué estrategias / patrones emplean las personas y qué ventajas y desventajas han encontrado las personas.

NÓTESE BIEN. Soy consciente de que esta es una pregunta muy subjetiva, y he tratado de hacerla una "buena" pregunta subjetiva según las pautas de SE.

Configuración (información sobre el entorno requerido para hacer el trabajo)

Cree una clase de configuración (para ser exigente: una interfaz + una implementación) cuyo propósito es proporcionar la información sobre el entorno. Esto hace que la configuración no sea diferente de otros objetos necesarios para que su objeto funcione (punto 1).

Parámetros (datos en los que se trabaja)

En un entorno orientado a objetos, los tipos de datos primitivos se pueden encapsular en objetos, por lo que esto también lleva al punto 1. Pero probablemente encontrará esta pregunta SO interesante, se trata exactamente de la situación de los parámetros primitivos en un constructor, cuando se utiliza un DI envase. En el ejemplo dado, el diseño podría mejorarse, lo que evitó la necesidad de tipos primitivos en el constructor por completo.

Lo que hago es un patrón de fábrica para estos casos.

No uso el objeto en sí mismo como una dependencia, pero creo un objeto de fábrica con un método Get que acepta parámetros que el contenedor no puede vincular automáticamente.

Ex.:

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }