I quadri di iniezione delle dipendenze presentano un rischio di dipendenza?

Sei completamente corretto - l'uso di un framework DI probabilmente renderà il tuo codice dipendente da quella cosa. In realtà, questo è troppo sorprendente, poiché questo è tipicamente vero per ogni altro framework o libreria di base, specialmente quando quella lib supporta il tuo progetto con alcune caratteristiche generiche usate ovunque nel tuo codice. Ad esempio, quando si decide di utilizzare una determinata infrastruttura dell'interfaccia utente o un framework Web, questa decisione è difficile da modificare in seguito non appena si crea una determinata quantità di codice basata su tale libreria. Quando decidi di utilizzare una classe specifica (forse non standard) String , non puoi facilmente modificare tale decisione in seguito. Tale decisione è architettonica, è come scegliere un determinato linguaggio di programmazione e provare a cambiare quella decisione dopo aver scritto > 100K linee di codice.

Il fatto che tutto il codice dipenda da un determinato framework potrebbe non essere un problema, a patto che faccia ciò che ci si aspetta da esso e fintanto che viene mantenuto correttamente. Ma può diventare un problema se non è il caso. Ci sono alcune strategie su come affrontare quella situazione:

• scegli un framework da un fornitore in cui credi di poterti offrire aggiornamenti e nuove versioni da diversi anni a partire da ora

• scegli un framework open source che abbia poche righe di codice (e una licenza adeguata), così puoi fare da solo qualsiasi manutenzione, visto che il venditore svanisce dal mercato

• scrivi il tuo framework

• convivi con la situazione fintanto che il venditore è disponibile, e quando svanisce davvero, scegli un diverso framework e prova a creare un adattatore che emuli il vecchio framework usando il nuovo

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

L'iniezione ordinaria 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 "software aziendale", utilizzato quando il grafico dell'oggetto è molto grande e complesso. Sospetto che il 95% delle applicazioni non lo richieda.

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

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

Direi che l'attuale DI è abbastanza maturo e non sono a conoscenza del fatto che molto accada lì. Non hai specificato la tua lingua, quindi parlando di Guice , è abbastanza non invadente e funziona con annotazioni Java standard (usa anche le proprie 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 la struttura di DI sarebbe più semplice di qualsiasi altra libreria (ad esempio, una modifica dell'interfaccia utente significa molto più lavoro).