Come funziona l'iniezione edilizia?
Ho il seguente codice:
public class AdvancedSearchController : Controller
{
private EmployeeController _employeeController;
public AdvancedSearchController(EmployeeController employeeController)
{
_employeeController = employeeController;
}
Cosa e come viene impostato il dipendenteController nel codice sopra? O passato al costruttore? Come avviene questa magia?
Non c'è magia a meno che tu non consideri la magia iniezione di dipendenza . Se ti trovi nel codice di avvio / bootstrap dell'app, quasi sicuramente troverai un contenitore IoC . Cerca in Global.asax.cs e segui i percorsi dal gestore di eventi di avvio dell'applicazione. Troverete la registrazione di componenti / servizi da qualche parte. A volte è giusto nel Global.asax, a volte è memorizzato in App_Start, a volte è nella radice, ea volte è altrove. È lì, però.
Le ultime versioni di ASP.NET vengono fornite con integrazione delle dipendenze integrata . Le ultime versioni di MVC l'hanno messo in uso .
Se stai utilizzando un framework più vecchio, ci sono molti contenitori di terze parti. Alcuni esempi:
Il principio è semplice. Si registra qualche tipo concreto come la rappresentazione attiva di un contratto. (Il contratto è solitamente un'interfaccia, ma potrebbe anche essere un tipo concreto.) Quindi nel codice, si fa sempre riferimento alle cose come contratti. Il contenitore ti dà il tipo registrato, ma non devi pensare ai dettagli. Ciò semplifica lo scambio di implementazioni in un unico luogo. Che a sua volta rende facile fare cose come pezzi di codice di prova usando oggetti finti prevedibili contro l'uso di oggetti complessi e imprevedibili. Gli oggetti complessi rendono difficile capire cosa stai veramente testando.
Oltre alla registrazione di tipi come contratti, i contenitori IoC fanno anche cose di fantasia come iniettare automaticamente i tipi nei componenti gestiti. Questo è quello che stai vedendo nel tuo esempio. Il contenitore gestisce i controller in modo che sappia fornire EmployeeController al AdvancedSearchController . Chissà? Forse ha iniettato un altro tipo in EmployeeController prima di inviarlo. (Non l'hai chiesto, ma non mi fa impazzire il passaggio dei controller in giro. Se hai qualche parola in proposito, lasciala. Sostituiscilo con alcuni non controller che fanno il lavoro necessario. .)
Alcuni contenitori ti permettono anche di decidere la durata dei tuoi tipi registrati - forse vengono istanziati ogni volta che vengono utilizzati, forse un oggetto rimane in agguato per la durata di una richiesta web (chiazza di petrolio per la gestione di un'unità di lavorare in un servizio web), o forse ce n'è sempre solo uno.
Se si utilizza ASP.NET Core MVC, questo è il modo in cui funziona: è necessario registrare i tipi nel metodo ConfigureServices della classe Startup.cs. Il metodo ConfigureServices viene chiamato dal runtime e aggiunge servizi al contenitore di iniezione delle dipendenze. Se non lo si registra qui, rispetto a quando viene chiamato il controller, verrà generato un errore. Verrà comunque creato ma restituirà un errore quando il controller viene avviato da qualcuno che accede a tale URL. Poiché il tuo oggetto è registrato, è quello che verrà iniettato nel controller.
Quindi, perché è utile? La tua classe startup.cs dovrebbe avere qualcosa come services.AddTransient IEmployeeController, EmployeeController (); Diciamo che volevi usare dati falsi per testare qualcosa. Dovresti cambiare quella linea per, services.AddTransient IEmployeeController, EmployeeControllerFakeData ();
La classe EmployeeControllerFakeData avrebbe solo alcuni dati hard-coded che si desidera testare. Poiché ora hai registrato EmployeeControllerFakeData che è quello che verrà iniettato nel costruttore.
Si sta prendendo la dipendenza di cui ha bisogno, sia che si tratti di dati di test, dati oracle, dati SQL, dati da un file ecc. e che si registrino, in modo che vengano iniettati dove è necessario.
Leggi altre domande sui tag dependency-injection .net constructors