Iniezione IoC / Dipendenza: spiegare il codice rispetto all’XML

Capisco fondamentalmente come funzionano i framework IoC, tuttavia una cosa che non capisco è come dovrebbe funzionare la configurazione basata sul codice. Con XML capisco come si possa aggiungere un nuovo assembly a un’applicazione distribuita, quindi modificare la configurazione in XML per includerla. Se l’applicazione è già distribuita (ad esempio, compilata in qualche modo), allora come possono essere apportate le modifiche al codice senza doverle ricompilare? O è quello che fanno le persone, basta cambiare configurazione nel codice e ricompilare?

Le dipendenze per lo scambio a caldo non sono l’unico objective dell’utilizzo di un contenitore DI.

L’iniezione di dipendenza (DI) è un principio che ci aiuta a sviluppare codice liberamente accoppiato . L’accoppiamento libero significa solo che possiamo variare il consumatore e il servizio indipendentemente l’uno dall’altro. Il modo in cui otteniamo ciò non è affrontato a questo livello.

I contenitori DI sono framework che aiutano a utilizzare le dipendenze dei cavi insieme. Sono più o meno solo librerie di utilità che ci aiutano ad applicare i modelli DI. Ancora una volta, come configuriamo un contenitore è perpendicolare al modo in cui consumiamo tali dipendenze.

Le configurazioni XML ci consentono di modificare la configurazione del contenitore senza ricompilazione . Codice come configurazione no.

Tuttavia, lo scambio delle dipendenze senza ricompilazione è in genere pertinente solo per un piccolo sottoinsieme di tutto il codice liberamente accoppiato. Per il resto, un approccio basato sulla convenzione è molto più efficace, perché tende ad essere meno fragile . Vedi qui per maggiori informazioni.

L’iniezione IoC e Dep può aiutare a consentire modifiche senza ricompilare (a seconda degli strumenti utilizzati), ma non è necessario. L’uso del codice da configurare riguarda la configurazione del contenitore, non le modifiche post-distribuzione. Sì, se apporti la modifica del codice normalmente devi ricompilare.

Cambio di codice senza ricompilazione, NON è ansible. La modifica della configurazione memorizzata in Web.Config, senza ricaricare il pool di app NON è ansible. Tuttavia, è ansible utilizzare il seguente scenario in cui non è necessario ricompilare il codice o riciclare il pool di applicazioni.
1. Archiviare i mapping in un file di configurazione esterno. (XML va bene)
2. Scrivi una funzione che carichi i mapping dal file esterno al tuo contenitore.
3. Esporre una funzione che ricarica i mapping.
4. Ogni volta che vuoi ricaricare i mapping, chiama semplicemente il metodo esposto e sei a posto 🙂

È anche ansible memorizzare i mapping, in un server SQL o in qualsiasi altro luogo. (Basta caricarli nel formato richiesto dal contenitore per elaborarlo.)

Solo perché un contenitore DI utilizza un codice per la configurazione non significa che nessuna configurazione può essere modificata senza ricompilare. Richiede di pensare esattamente a ciò che si desidera configurare in quel modo e di fornire alcuni modi per modificare tale configurazione (ad esempio attraverso un file delle proprietà).