Perché abbiamo bisogno di quadri per l'iniezione di dipendenza? [chiuso]

Question

Perché abbiamo bisogno di quadri per l'iniezione di dipendenza? [chiuso]

#1 da (25 voti)
#2 da (11 voti)
#3 da (5 voti)
#4 da (1 voti)

38

Ho letto di più sul principio di Inversion of Control e Dependency Injection come implementazione di esso e sono abbastanza sicuro di averlo capito.

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

Se è così semplice, che sembra essere, perché abbiamo bisogno di framework come spring o guice che implementino questo con annotazioni? Mi manca qualcosa di fondamentale qui? Sto davvero cercando di capire quale sia l'uso dei framework di Dependency Injection.

Modifica: a proposito del 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 è correlato a DI.

dependency-injection inversion-of-control spring google-guice

posta timsworth 17.10.2015 - 21:12

fonte

4 risposte

11

Perché abbiamo bisogno di DI (Dependency Injection)?

Il meccanismo DI separa la produzione dell'oggetto dal consumo dell'oggetto. Le dipendenze di cui un oggetto ha bisogno sono consegnate in modo trasparente dall'esterno. Il vantaggio del meccanismo è chiaro: puoi in qualsiasi momento scambiare dipendenze, ad es. utilizzando un oggetto Null a scopo di test.
Come è fatto?

Ci sono diversi modi per raggiungere l'obiettivo:
- Iniezione delle dipendenze tramite l'iniezione del costruttore
- Iniezione tramite getter / setter
- Iniezione di interfacce
Abbiamo bisogno dei quadri DI?

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

D'altra parte, i framework ti danno una mano, gestendo gli oggetti:
- Vi aiutano a cablare relazioni di oggetti complesse. Non devi scrivere codice di codice, generare istanze e passarle agli oggetti appropriati
- Ti aiutano a controllare quando viene creato un oggetto: puoi creare istanze durante il bootstrap dell'applicazione, ma in alcuni casi una creazione lenta - solo quando necessario - è meglio
- Ti aiutano a controllare quante istanze vengono create: una per durata dell'applicazione o una per richiesta (nel caso tu stia facendo programmazione web)

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

risposta data 18.10.2015 - 01:08

fonte

5

Con la primavera, è soprattutto una questione di convenienza.

Se hai classe TopLevel che è costruisce la classe MiddleLevel che costruisce la classe LowLevel , e ti rendi conto che hai bisogno di un nuovo parametro costruttore su LowLevel , devi anche aggiungerlo a TopLevel , e a MiddleLevel , semplicemente in modo che quando è il momento per MiddleLevel di costruire un LowLevel il valore sarà disponibile in modo che possa essere passato al suo costruttore. Con la primavera, devi solo aggiungere un'annotazione.

Inoltre, con spring, è possibile definire le dipendenze in un file di configurazione esterno invece di xml, e questo presumibilmente ti dà la possibilità di generare un nuovo sistema con un cablaggio completamente diverso "senza modificare alcun codice". (IMHO questo è completamente indirizzato male, perché l'alterazione di xml non è molto diversa dalla modifica del codice, e in realtà il codice di solito ha un controllo degli errori e un controllo dei tipi di gran lunga migliori di quelli di xml.)

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

risposta data 17.10.2015 - 21:36

fonte

1

Alcuni anni fa ho scritto un programma per monitorare pagine web, portlet web, persino alcune tabelle di database, presso un'azienda per la quale lavoravo. Volevo che fosse abbastanza flessibile da consentire all'utente di specificare quali monitor eseguire e con quali parametri (url, accessi, criteri di successo, ecc.). Così l'ho scritto per leggere da un file XML e utilizzare la reflection Java per creare un'istanza delle classi specificate e utilizzare i metodi setter per impostare i parametri specificati.

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

Quindi nel mio caso l'ho trovato

L'utilizzo di un framework di dipendenze per le iniezioni contribuisce a rendere flessibile il programma e rende più semplice specificare come funzionerà (naturalmente con parametri ben definiti).
L'uso di un framework DI di terze parti ti impedisce di dover reinventare la ruota.

risposta data 19.10.2015 - 14:41

fonte

Leggi altre domande sui tag dependency-injection inversion-of-control spring google-guice

Perché PHP non supporta l'overloading delle funzioni? I problemi con Evitare il Puffing Denominare classi con namespace

score 25 · Accepted Answer

Non abbiamo bisogno delle strutture. È completamente possibile implementare manualmente l'integrazione delle dipendenze, anche per un progetto relativamente grande.

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

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