I framework di iniezione di dipendenza rappresentano un rischio di dipendenza?

Ho eseguito il refactoring di un sistema esistente per utilizzare l'iniezione delle dipendenze e il lavoro è andato liscio.

Dopo un po 'ho notato che un gran numero di librerie interne è diventato dipendente dal framework DI che ho usato. Di conseguenza l'intero progetto ora dipende da questo framework di terze parti.

Ho visto un'ironia nel disaccoppiare tutte le dipendenze rendendole dipendenti da una libreria condivisa.

La mia prima reazione è stata quella di creare una libreria wrapper attorno al framework delle dipendenze. Pertanto, potrei sostituire questo quadro, se necessario. Dopo aver stimato il lavoro coinvolto, mi sono reso conto che l'API risultante sarebbe stata simile al framework esistente e quindi avrebbe reso più difficile la sua sostituzione. Quindi ho abbandonato l'idea.

La mia preoccupazione è che il framework DI che sto usando diventi obsoleto o debba essere sostituito.

Esiste un modello di sviluppo quando si lavora con DI che riduce l'accoppiamento tra un progetto e il framework DI?

Hai pienamente ragione: l'uso di un framework DI molto probabilmente renderà il tuo codice dipendente da quella cosa. In realtà, questo è troppo sorprendente, dal momento che questo è in genere vero per ogni altro framework o libreria di base, specialmente quando quella lib supporta il tuo progetto con alcune funzionalità generiche utilizzate ovunque nel tuo codice. Ad esempio, quando si decide di utilizzare un determinato framework dell'interfaccia utente o un framework Web, questa decisione è difficile da modificare in seguito non appena si crea una determinata quantità di codice basato su quella libreria. Quando decidi di utilizzare una Stringclasse specifica (forse non standard) , non puoi facilmente cambiare quella decisione in seguito. Tale decisione è di tipo architettonico, è come scegliere un certo linguaggio di programmazione e provare a cambiare quella decisione dopo aver scritto> 100K righe di codice.

Far dipendere tutto il tuo codice da un determinato framework potrebbe non essere un problema fintanto che fa quello che ti aspetti da esso e fintanto che è gestito correttamente. Ma può diventare un problema se non è così. Ci sono alcune strategie su come affrontare quella situazione:

• scegli un framework da un fornitore in cui credi che possa fornirti aggiornamenti e nuove versioni per diversi anni

• scegli un framework open source che abbia poche righe di codice sufficienti (e una licenza adeguata), in modo da poter eseguire qualsiasi manutenzione da solo, dato che il fornitore scompare dal mercato

• scrivi il tuo framework

• convivere con la situazione fintanto che il fornitore è disponibile e quando svanisce davvero, scegliere un framework diverso e provare a creare un adattatore che emuli il vecchio framework utilizzando il nuovo

L'idea di creare una libreria wrapper in anticipo non è affatto nuova, ma raramente ho visto che funziona, dal momento che dovresti fare ipotesi per una situazione futura per la quale non sai se o quando ti colpirà, e cosa apparirà il "nuovo" framework. D'altra parte, alcuni anni fa abbiamo scambiato con successo un framework UI completo in un progetto C ++ con ~ 120K di righe di codice applicando la strategia dell'adattatore che ho menzionato sopra.

L'iniezione ordinaria da parte del costruttore non richiede affatto un framework. L'unica cosa che perdi è la possibilità di centralizzare le tue dipendenze in un file di configurazione.

I contenitori DI sono un modello di "software aziendale", utilizzato quando il grafico a oggetti è molto grande e complesso. Sospetto che il 95% delle domande non lo richieda.

Non credo che i framework DI possano diventare presto obsoleti in qualsiasi momento. Cosa dovrebbe accadere per renderlo obsoleto?

• Un'invenzione di un modello nuovo e più intelligente forse? Comunque dovrebbe apparire, richiederebbe cambiamenti molto più grandi nel codice.
• Un cambiamento nella lingua forse? Persino peggio.

Direi che l'attuale DI è abbastanza maturo e non sono consapevole del fatto che accada molto lì. Non hai specificato la tua lingua, quindi parlando di Guice , è abbastanza non invadente e funziona con le annotazioni Java standard (usa anche la propria per cose non standardizzate, ma raramente ne hai bisogno). È open source, ampiamente utilizzato e con licenza Apache. Quale potrebbe essere il problema?

Sono abbastanza sicuro che cambiare il DI framework sarebbe un ordine di grandezza più semplice che cambiare qualsiasi altra libreria (ad esempio, una modifica dell'interfaccia utente significa molto più lavoro).