Perché abbiamo bisogno di framework per l'iniezione delle dipendenze? [chiuso]

42

Ho letto di più sul principio dell'inversione del controllo e dell'iniezione delle dipendenze come una sua attuazione e sono abbastanza sicuro di capirlo.

Sembra in sostanza dire "non dichiarare le istanze dei membri della classe all'interno della classe". Piuttosto che le istanze dovrebbero essere passate e assegnate attraverso il costruttore; 'iniettato' nella classe da una fonte esterna.

Se è così semplice, come sembra, perché abbiamo bisogno di framework come spring o guice che implementano questo con le annotazioni? Mi sto perdendo qualcosa di fondamentale qui? Faccio davvero fatica a capire quale sia l'uso dei framework di Iniezione delle dipendenze.

Modifica: circa il possibile duplicato, credo che la mia domanda sia più unica in quanto si tratta di framework DI in generale, non solo di Spring. Spring non è solo un framework DI, quindi ci sono molte ragioni per cui qualcuno vorrebbe usare Spring che non sono correlate a DI.

— timsworth
fonte

Possibile duplicato di Cosa fa il framework Spring? Dovrei usarlo? Perché o perché no?

— moscerino del

11

Sono utili per spostare gli errori in runtime anziché in fase di compilazione.

— Den

1

@den Perché dovremmo voler farlo? Ciò sembra violare rapidamente il fallimento

— QUESTO UTENTE HA BISOGNO DI AIUTO

26

Non abbiamo bisogno dei quadri. È del tutto possibile implementare manualmente l'iniezione di dipendenza, anche per un progetto relativamente grande.

D'altra parte, l'uso di un framework rende più semplice, in particolare uno basato su annotazioni o rilevamento automatico delle dipendenze, in quanto semplifica il processo: se decido che ho bisogno di una nuova dipendenza in una classe, tutto quello che devo fare è aggiungere al costruttore (o dichiarare un setter) e l'oggetto viene iniettato - Non ho bisogno di cambiare alcun codice di istanza.

Inoltre, i framework contengono spesso altre funzionalità utili. Spring, ad esempio, contiene un framework utile per la programmazione orientata all'aspetto, inclusa la demarcazione delle transazioni dichiarative (che è estremamente utile) e una varietà di implementazioni dell'adattatore che rendono più facile l'integrazione di molte librerie di terze parti.

— Jules
fonte

8

Colpire nel segno. Non ne abbiamo bisogno. Semplificano la vita di grandi progetti. Onestamente, trovo che i framework siano più fastidiosi di quanto valgano per progetti più piccoli. Incoraggerei l'OP a non confondere l'iniezione di dipendenza con i framework che lo supportano.

— RubberDuck,

1

ben detto. E perché reinventare la ruota quando qualcun altro ne ha già realizzata una bella e rotonda?

— jwenting

Esattamente quello. Tranne che non ho bisogno di cambiare alcun codice di istanza - ovviamente, non esiste un codice di istanza ;-)

— Mathieu Guindon,

Sembra proprio che le tue librerie DI facciano schifo. I bravi possono indovinare la classe a creare un'istanza usando la riflessione.

— Florian Margaine,

2

chiunque utilizzi reflection per l'elaborazione runtime lo sta facendo in modo sbagliato. La riflessione è una di quelle tecnologie che, solo perché puoi fare qualcosa, non significa che dovresti.

— gbjbaanb,

12

Perché abbiamo bisogno di DI (Dependency Injection)?

Il meccanismo DI separa la produzione di oggetti dal consumo di oggetti. Le dipendenze di cui un oggetto necessita sono fornite in modo trasparente dall'esterno. Il vantaggio del meccanismo è evidente: è possibile in qualsiasi momento sostituire le dipendenze, ad esempio utilizzando un oggetto null a scopo di test.
Com'è fatto?

Esistono diversi modi per raggiungere l'obiettivo:
- Iniezione di dipendenze tramite iniezione del costruttore
- Iniezione tramite getter / setter
- Iniezione di interfaccia
Abbiamo bisogno di framework DI?

No. Niente affatto. Potresti semplicemente passare manualmente tutte le istanze ad altri oggetti. Se hai una piccola applicazione, non è necessario un contenitore a molla.

D'altra parte, i framework ti danno una mano, gestendo gli oggetti:
- Ti aiutano a collegare relazioni complesse con gli oggetti. Non devi scrivere nessun codice boilerplate, per generare istanze e passarle agli oggetti appropriati
- Ti aiutano a controllare quando viene creato un oggetto: potresti creare istanze durante il bootstrap dell'applicazione, ma in alcuni casi una creazione pigra - solo quando necessario - è migliore
- Ti aiutano a controllare quante istanze vengono create: una per la durata dell'applicazione o una per richiesta (nel caso in cui tu stia eseguendo una programmazione Web)

Se il tuo progetto ha una dimensione appropriata - se senti la necessità di scrivere meno codice sulla caldaia - ha perfettamente senso usare un framework (DI-). Ci sono più pro che contro.

— Thomas Junk
fonte

2

È possibile utilizzare le librerie DI senza utilizzare un framework.

— Florian Margaine,

5

Con la primavera, è soprattutto una questione di convenienza.

Se hai una classe TopLevelche è una classe di costrutti MiddleLevelche costruisce una classe LowLevele ti rendi conto di aver bisogno di un nuovo parametro del costruttore su LowLevel, devi anche aggiungerlo a TopLevel, e a MiddleLevel, semplicemente in modo che quando sarà il momento MiddleLeveldi costruire un LowLevelvalore sarà disponibile in modo che possa essere passato al suo costruttore. Con la primavera, aggiungi semplicemente un'annotazione.

Inoltre, con Spring, è possibile definire le dipendenze in un file di configurazione esterno anziché in xml, e questo presumibilmente ti dà la possibilità di generare un nuovo sistema con un cablaggio completamente diverso "senza cambiare alcun codice". (IMHO questo è completamente mal indirizzato, perché l'alterazione di xml non è molto diversa dall'alterazione del codice, e in realtà, il codice di solito ha un controllo degli errori e un controllo del tipo di gran lunga migliore rispetto a xml.)

Un'altra cosa è che molte persone hanno paura dei costruttori; non li capiscono, non gli piacciono, preferiscono non usarli.

— Mike Nakis
fonte

3

Principalmente d'accordo, specialmente con l'osservazione XML. IMHO, avere paura dei costruttori è probabilmente una cattiva ragione per usare un framework DI.

— Robert Harvey,

2

IMHO, avere paura dei costruttori è una buona ragione per stare lontano dalla programmazione. C -: =

— Mike Nakis,

5

Ma come è un vantaggio rispetto a una fabbrica (statica o meno)? (Il che ha il vantaggio di essere un'opzione che puoi usare nel modo appropriato, mentre la primavera sembra essere un tutto o niente alla pari)

— Richard Tingle,

@RichardTingle Spring può rappresentare un vantaggio principalmente a causa di tutte le altre cose che fa oltre a DI, perché ovviamente puoi ottenere DI in molti altri modi, essendo le fabbriche statiche una. (Uno dei meno belli, ma comunque.) Ma la domanda è se è necessario usare la molla per ottenere DI, ed è quello a cui ho cercato di rispondere: in fondo, non è necessario, solo una comodità .

— Mike Nakis,

Questo è un esempio di ciò che DI non è. "TopLevel" non dovrebbe creare MiddleLevel, ma dovrebbe riceverlo durante la costruzione TopLevelcome argomento per il costruttore. Allo stesso modo MiddleLeveldovrebbe ricevere un LowLevelnel suo costruttore.

— Più chiaro il

1

Qualche anno fa ho scritto un programma per monitorare pagine Web, portlet Web, persino alcune tabelle di database, presso un'azienda per cui lavoravo. Volevo che fosse abbastanza flessibile che l'utente potesse specificare quali monitor sarebbero stati eseguiti e con quali parametri (URL, accessi, criteri di successo, ecc.). Così l'ho scritto per leggere da un file XML e usare la riflessione Java per creare un'istanza delle classi specificate e usare i metodi setter per impostare i parametri specificati.

Più tardi ho scoperto che la primavera farà la stessa cosa per te e molto altro ancora.

Quindi nel mio caso l'ho trovato

L'uso di un framework di iniezione delle dipendenze aiuta a rendere flessibile il programma e rende più semplice specificare come funzionerà (ovviamente entro parametri ben definiti).
L'uso di un framework DI di terze parti ti impedisce di reinventare la ruota.

— Paul J Abernathy
fonte

4

Potresti spiegarci di più sul perché definire quale classe concreta usare è meglio all'interno di un xml piuttosto che all'interno di un file java. Questa è la cosa che non ho mai capito.

— Richard Tingle,

1

Non è un proiettile magico, ma un vantaggio nell'uso dei file di configurazione è che, almeno in teoria, sono più facili da modificare rispetto al codice. Inoltre, possono essere modificati da un utente che esegue il programma ma non ha accesso al codice sorgente. Nell'esempio che ho fornito del mio programma di iniezione di dipendenza grezza, a volte cambiavo il file di configurazione XML in modo da poter cambiare il modo in cui il programma veniva eseguito anche se ero io a scriverlo. Se non hai bisogno della configurabilità esterna, può essere più semplice farlo con il codice. Avevo un altro lavoro in cui facevamo tutte le DI nel codice e che funzionava bene.

— Paul J Abernathy,