Come gestite la configurazione con l'iniezione delle dipendenze?

Sono un grande fan di DI / IOC. È ottimo per gestire / sottrarre dipendenze difficili e semplifica la vita.

Tuttavia ho una piccola lamentela, che non sono sicuro di come risolvere.

L'idea di base in DI / IOC è che quando un oggetto viene istanziato, tutte le sue dipendenze sono pre-riempite all'interno del costruttore.

Tuttavia IMHO ci sono diversi tipi di parametri per i costruttori (specialmente quando i tuoi oggetti sono immutabili).

Dipendenze (oggetti necessari per far funzionare l'oggetto)
Configurazione (informazioni sull'ambiente necessarie per funzionare)
Parametri (dati su cui si lavora)

Trovo che il CIO funzioni bene con le dipendenze. Ma sto ancora cercando di trovare il modo migliore per affrontare gli altri due. Tuttavia, poiché il costruttore viene eseguito per essere eseguito dal contenitore IOC, sembra che sia necessario posizionare questi elementi nel contenitore IOC.

Mi piacerebbe sapere quali strategie / modelli adottano le persone e quali vantaggi e svantaggi hanno trovato le persone.

NB. Sono consapevole che questa è una domanda altamente soggettiva e ho cercato di renderla una "buona" domanda soggettiva secondo le linee guida SE.

design-patterns configuration-management inversion-of-control

— Arts
fonte

Per "Configurazione" intendi la configurazione dev-environment (come Sviluppo o Produzione)? Se è così, di solito lo gestisco come una dipendenza tradizionale.

— MetaFight,

Meglio costruire con dipendenze ma configurazione predefinita in modo che l'oggetto sia ben formato. Chiamare metodi aggiuntivi per impostare la configurazione e altri parametri. Fare troppo nel ctor è una brutta cosa.

— david.pfx,

I am still trying to work out the best way to deal with the other two- Passali come parametri ordinari al tuo oggetto?

— Robert Harvey,

@RobertHarvey oggetti immutabili? Rendono il debug molto più semplice.

— Articoli

Risposte:

Configurazione (informazioni sull'ambiente necessarie per funzionare)

Creare una classe di configurazione (per essere pignoli: un'interfaccia + un'implementazione) lo scopo è quello di fornire le informazioni sull'ambiente. Ciò rende la configurazione in alcun modo diversa dagli altri oggetti necessari affinché l'oggetto funzioni (punto 1).

Parametri (dati su cui si lavora)

In un ambiente orientato agli oggetti, i tipi di dati primitivi possono essere incapsulati negli oggetti, quindi questo porta anche al punto 1. Ma probabilmente troverai interessante questa domanda SO , si occupa esattamente della situazione dei parametri primitivi in un costruttore, quando si usa un DI contenitore. Nell'esempio dato, il design potrebbe essere migliorato, il che ha evitato completamente la necessità di tipi primitivi nel costruttore.

— Doc Brown
fonte

Quello che faccio è uno schema di fabbrica per questi casi.

Non utilizzo l'oggetto stesso come dipendenza ma creo un oggetto factory con un metodo Get che accetta parametri che non possono essere associati automaticamente dal contenitore.

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);
 }

— Vilém Procházka
fonte