Quando si utilizza IoC appropriato?

Question

Capisco cosa sono e stanno leggendo i contenitori IoC su Structure Map. La tecnologia sembra abbastanza facile da usare. La mia domanda è, qual è il livello appropriato di granularità per l'utilizzo di un contenitore IoC?

compaiono i seguenti possibili livelli di domanda di CIO:

1. pausa ogni dipendenza tra tutti gli oggetti - certamente eccessivo.
2. Dipendenze di interruzione tra tutti gli oggetti principali come oggetti dominio, classi di supporto e componenti all'interno di sottosistemi.
3. Utilizzare IoC in combinazione con una facciata per avvolgere un sottosistema (come la registrazione) con un'interfaccia pubblica e quindi interrompere la dipendenza da tale interfaccia.

So che la risposta a questa domanda è "dipende", ma dalla vostra esperienza, da cosa dipende la risposta? La dimensione del progetto è un fattore?

Inoltre, dove non ha senso utilizzare IoC?

Answer 1

L'idea non è di rompere le dipendenze tra gli oggetti di dominio, è quello di proteggere il dominio dal mondo esterno. Gli oggetti di dominio dovrebbero essere relativi a qualsiasi problema aziendale che si sta risolvendo e non a database, registrazione, memorizzazione nella cache, contesti http, servizi di riposo, ecc ...

Questo articolo parla dello spostamento delle responsabilità dagli oggetti e nel contenitore IoC.

http://www.agileatwork.com/captcha-and-inversion-of-control/

Answer 2

Penso che abbia senso usarlo quando sai che scriverò molti test unitari in quanto rende più facile la costruzione di questi test. Inoltre, consente (tramite configurazione esterna) di modificare il comportamento degli oggetti durante il runtime.

Non ha senso utilizzare IoC su progetti o progetti più piccoli che non richiedono un disaccoppiamento massiccio.

Answer 3

Direi che ha più senso quando sai che avrai bisogno di un'applicazione flessibile perché i requisiti cambieranno spesso o quando lavorerai su un grande sistema con un team di sviluppatori. Aiuta quando lavori in una squadra perché puoi lavorare sul tuo pezzo e lasciare che IoC si prenda cura delle tue dipendenze.

Answer 4

Uno scenario per il CIO è quando una decisione di implementazione specifica viene contestata dal team di sviluppo. IOC offre la flessibilità di poter sostituire le implementazioni con il minimo attrito. Questa è più una considerazione tattica di qualsiasi altra cosa.

Answer 5

Beh, CIO non ha molto senso se si sta programmando una componente molto concreta che non avrà più tipi di implementazioni ...

Per esempio; Dite che state programmando un lettore di documenti per la vostra azienda e sapete per certo che la regola aziendale dietro il lettore è che non leggerà mai nessun altro tipo di documento, quindi un documento MS Word. In questo caso, i test di unità non richiedono realmente un accoppiamento lento dell'iniezione di dipendenza perché il componente che si sta testando non dipenderà mai da altro che da un documento MS Word. Potrebbe essere eccessivo utilizzare un contenitore IOC per risolvere il tipo di lettore.