Perché si dovrebbe usare un contenitore DI di terze parti sul contenitore DI di base ASP.NET integrato?

Come attualmente c’è mancanza di documentazione sul tema DI – Iniezione di dipendenza . Qualcuno può aiutarmi a capire quanto segue:

  1. Qual è la differenza tra queste registrazioni?

    public void ConfigureServices(IServiceCollection services) { services.AddTransient(); services.AddScoped(); services.AddSingleton(); services.AddInstance(service); } 
  2. Quali sono i pro / contro dell’uso del DI integrato rispetto a soluzioni esistenti come (NInject, Autofac, Structure Map)?
  3. Quali sono le attuali limitazioni dell’iniezione di dipendenza predefinita (se presente)?

Per lo sviluppo del prodotto di qualsiasi applicazione di dimensioni considerevoli che segue i principi SOLID, il contenitore DI incorporato di vNext sarà inutile, in quanto:

  • Non ti aiuta a verificare la tua configurazione, rendendo davvero difficile diagnosticare problemi derivanti da errate configurazioni comuni. In un’applicazione di dimensioni ragionevoli, in realtà è abbastanza difficile individuare questi errori da soli.
  • È imansible applicare le preoccupazioni trasversali usando intercettatori o decoratori in modo sostenibile. Ciò rende molto costoso il mantenimento di qualsiasi applicazione di dimensioni ragionevoli.
  • Sebbene supporti la mapping di astrazioni generiche aperte per aprire implementazioni generiche, la sua implementazione è piuttosto ingenua e non è in grado di lavorare con tipi generici con vincoli di tipo e mappature di tipi generici più complessi.
  • Non è ansible effettuare registrazioni condizionali, in modo tale che le registrazioni vengano solo iniettate a un determinato insieme di consumatori.

Se inizi con un progetto nuovo e semplice, il mio consiglio è di applicare Pure DI (che significa componenti cablati a mano senza l’uso di un contenitore) e risolvere i tuoi tipi collegando il tuo IControllerActivator personalizzato . Successivamente, quando funzionalità come la registrazione e la decorazione di lotti migliorerebbero la manutenibilità della composizione della radice , passare a una delle librerie DI stabilite che si adatta alle proprie esigenze.

Qui è spiegato:

  • Transitorio: una nuova istanza viene creata ogni volta
  • Scoped: viene creata una singola istanza all’interno dell’ambito corrente. È equivalente a Singleton nell’ambito corrente
  • Singleton: viene creata una singola istanza e si comporta come un singleton
  • Istanza: viene fornita un’istanza specifica per tutto il tempo. Sei responsabile della sua creazione iniziale

La versione Alpha aveva questo limite:

  • Supporta solo l’iniezione del costruttore
  • Può risolvere solo i tipi con uno e un solo costruttore pubblico
  • Non supporta funzionalità avanzate (come per l’ambito thread o auto discovery)

Se non stai scrivendo un contenitore DI di default del prodotto veramente complicato, dovrebbe essere sufficiente per te. In altri casi puoi provare le librerie che hai già menzionato che hanno funzionalità avanzate.

Il mio consiglio sarebbe quello di iniziare con quello predefinito e modificare l’implementazione quando (se) si colpisce qualcosa che non si può fare con esso.

Qual è la differenza tra queste registrazioni?

  • Transitorio – istanziato ogni volta che viene recuperato
  • Scoped – istanziato una volta per richiesta http e sarà disponibile per tutta la durata della richiesta http
  • Singleton – istanziato una volta e sarà disponibile per l’intera vita della tua applicazione
  • Istanza – equivalente a singleton tranne per il fatto che si fornisce l’istanza dell’object al posto del framework che crea l’istanza

Fonte: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles , http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency- iniezione-in-6-passi /

Per rispondere alla tua prima domanda: sembra che i documenti ASP.NET siano stati aggiornati e ora dichiari chiaramente qual è ciascun tipo di registrazione per:

I servizi ASP.NET possono essere configurati con le seguenti durate:

transitorio

I servizi a vita temporanea vengono creati ogni volta che vengono richiesti. Questa vita funziona al meglio per un servizio leggero e senza stato.

scoped

I servizi a durata scopata vengono creati una volta per richiesta.

Singleton

I servizi a vita singola di Singleton vengono creati la prima volta in cui vengono richiesti e quindi ogni richiesta successiva utilizzerà la stessa istanza. Se l’applicazione richiede un comportamento singleton, è consigliabile consentire al contenitore dei servizi di gestire la durata del servizio anziché implementare il modello di progettazione singleton e gestire la durata del proprio object nella class.

Istanza [solo per RTM!]

È ansible scegliere di aggiungere un’istanza direttamente al contenitore dei servizi. In tal caso, questa istanza verrà utilizzata per tutte le richieste successive (questa tecnica creerà un’istanza con ambito Singleton). Una differenza fondamentale tra i servizi di istanza e Singleton è che il servizio Istanza viene creato in ConfiguraServizi, mentre il servizio Singleton viene caricato in modalità lazy la prima volta che viene richiesto.


Aggiornato in RTM

Si noti che nell’istanza di Asp.Net Core RTM è stata rimossa l’istanza. L’istanza è fondamentalmente la stessa cosa di Singleton, ma avevano una semantica di inizializzazione diversa (Singleton era pigro caricato). Ma ora non ci sono API AddInstance, solo AddSignleton che può prendere istanza già creata.