Qual è l'uso di un framework IoC in un'applicazione MVC?

Question

Sto cercando di capire l'uso di un framework IoC come StructureMap, ma non posso fare a meno di pensare che questi "modelli di progettazione" sono solo assurdità, rendendo il codice ancora più complesso.

Vorrei iniziare con un esempio in cui penso che un IoC sia in qualche modo utile.

Penso che un IoC può essere utile quando si ha a che fare con la creazione di istanze di classi di controller in un framework MVC. In questo caso sto pensando al framework .NET MVC.

Normalmente l'istanziazione della classe controller viene gestita dal framework. Ciò significa che non è possibile passare alcun parametro al costruttore della classe controller. È qui che un framework IoC può rivelarsi utile. Da qualche parte in un container IoC si specifica quale classe deve essere istanziata e trasmessa ai controllori constructor quando viene richiamata la classe controller.

Questo è utile anche quando si desidera testare il controller dell'unità, perché è possibile prendere in giro l'oggetto che gli viene passato.

Ma come ho detto, posso capire un po 'perché le persone vogliono usarlo per le loro classi di controller. Ma non al di fuori di questo. Da lì in avanti puoi semplicemente fare il normale Dipendenza iniezione.

Ma perché non fare semplicemente in questo modo:

public class SomeController 
{ 
    public SomeController() : this(new SomeObj()) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 

Ora non c'è bisogno di utilizzare alcun 3rd IoC quadro partito che significa anche una curva di apprendimento più basso. Dal momento che non devi andare anche nelle specifiche di quel quadro.

È ancora possibile prendere in giro l'oggetto nei test di unità. Quindi nessun problema neanche lì.

L'unica cosa che si può dire è "ma ora la tua classe è strettamente accoppiata a SomeObj". Questo è vero. Ma a chi importa!? È una classe controller! Non ho intenzione di riutilizzare quella lezione, mai .. Allora perché mai dovrei preoccuparmi di quel accoppiamento stretto ..? Posso prendere in giro l'oggetto che è passato ad esso. Questa è l'unica cosa importante.

Quindi perché dovrei preoccuparmi di usare un IoC? Mi manca VERAMENTE il punto ...? Per me il pattern IoC è solo un pattern sopravvalutato. Aggiunta di più livelli complessi alla tua applicazione ...

Answer 1

farle una buona domanda e nel tuo esempio direi che un CIO sarebbe/potrebbe essere eccessivo, ma considera il tuo codice esteso a quanto segue e quindi potresti iniziare a vedere il vantaggio di avere un IoC che fa tutto questo per te.

public class SomeController 
{ 
    public SomeController() : this(new SomeObj(new configuration(), new SomethingElse(new SomethingElseToo()))) 
    { 
    } 

    publiv SomeController(SomeObj obj) 
    { 
     this.obj = obj; 
    } 
} 

Answer 2

Ci sono più cose che un contenitore di IoC può fare per te.

La più ovvia sta fornendo l'implementazione per le dipendenze, che ha un senso altrove, non solo in controller - Se si decide di sostituire SomeObj con SomeObj2, lo si può fare in un solo luogo, invece di 57 posti.

Un altro sta gestendo i problemi del ciclo di vita, cioè è possibile specificare l'ambito di un oggetto (singleton, per-thread, per-request, transient ...).

Inoltre, il contenitore IoC può impostare le dipendenze opzionali (ad es.iniezione di proprietà), che è più facile che scrivere questo:

var svc = new Service(new MyRepository()) 
svc.Logger = logger; 
svc.XY = xy 

e tutte le buone ragioni esposte qui: Why do I need an IoC container as opposed to straightforward DI code?

Answer 3

Ma chi se ne frega !? È una classe controller! Non ho intenzione di riutilizzare quel di classe, mai ..

Questo è un buon punto, ma considerare come più pulito è il codice se avete nidificato dipendenze, con diversi cicli di vita . Ad esempio è possibile avere un singleton a livello di applicazione, qualcosa che deve essere "per richiesta" e così via. L'IoC rende solo il tuo codice più pulito e facile da modificare.