Come gestite la configurazione con l'iniezione di dipendenza?

15

Sono un grande fan di DI / IOC. È ottimo per gestire / astrarre le dipendenze e rendere la vita un po 'più semplice.

Tuttavia ho un piccolo problema con esso, che non so 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).

  1. Dipendenze (oggetti necessari affinché il tuo oggetto funzioni)
  2. Configurazione (informazioni sull'ambiente necessarie per svolgere il lavoro)
  3. Parametri (dati su cui il lavoro è stato eseguito)

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

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

NB. Sono consapevole che questa è una domanda altamente soggettiva e ho cercato di farne una "buona" domanda soggettiva come da linee guida SE.

    
posta ArTs 10.02.2014 - 11:36
fonte

2 risposte

9

Configuration (information about the environment required to do work)

Crea una classe di configurazione (per essere pignoli: un'interfaccia + un'implementazione) che ha lo scopo di fornire le informazioni sull'ambiente. Ciò rende la configurazione in alcun modo diversa dagli altri oggetti richiesti per il lavoro dell'oggetto (punto 1).

Parameters (Data that work is done on)

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

    
risposta data 10.02.2014 - 13:33
fonte
1

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.

Esempio:.

 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);
 }
    
risposta data 14.02.2014 - 20:04
fonte