Continua Supporto Ninject in ASP.NET MVC 6?

Question

Sono stato molto contento di usare lo Ninject per molto tempo ora, e mi piace molto, ma mi trovo di fronte a una scelta difficile dal momento che il rilascio di ASP.NET 5 e MVC 6.

Fondamentalmente, fuori dalla porta, Microsoft ha rivelato il proprio sistema di iniezione delle dipendenze; Quale è quello che a mia conoscenza ha ottenuto molte critiche. Ma il mio problema più grande sta nel modo in cui influisce su altre librerie.

Da another question I asked e other resources online, sembra che Ninject non funziona out of the box con MVC 6. Sebbene ci sia una "soluzione" dato nella forma di una biblioteca verbose Microsoft.Framework.DependencyInjection.Ninject and Ninject. Questo è ancora più complicato perché quella libreria richiede l'aggiunta di https://www.myget.org/F/aspnetmaster/ al tuo elenco di feed NuGet.

Ho fatto qualche ricerca e ho trovato dove è ospitata questa libreria; Sembra a posto, sembra funzionare bene da quello che posso dire, ma ci sono alcune cose che mi preoccupano.

• La biblioteca non sembra davvero di essere guidato dai creatori Ninject
• La biblioteca è sepolto piuttosto profondo in un repository oscura
• L'attuale risorse Ninject on-line non menzionano

Così in fondo, sono molto preoccupato per il fatto che si tratti di una sorta di aiutante di banda e che il supporto per Ninject (e anche per altre librerie di contenitori) si sta estinguendo. C'è qualche informazione nascosta che non sto scoprendo?

Answer 1

• La biblioteca non sembra davvero di essere guidato dai Ninject creatori

quella libreria, e sembrerebbe these also, cercare di essere Microsoft ha creato campioni di fornitori di iniezione di dipendenza che erano removed in beta7. Si noti che il collegamento a DI in MVC 6 a cui fa riferimento il numero original question dice quanto segue;

Questi adattatori di contenitori DI sono temporanei e sono lì per riferimento; ci aspettiamo che alla fine verranno rimossi e sostituiti dai rispettivi proprietari di container .

Come dovrebbero essere. Microsoft non dovrebbe essere responsabile per il mantenimento di fornitori di terze parti.

• La biblioteca è sepolto piuttosto profondo in un oscuro repository

Se non si è a conoscenza, ASP.NET 5 è ancora in sviluppo.Beta 7 è disponibile su nuget come pre-release, ma ci sono anche altre fonti incluse;

• https://github.com/aspnet/ (codice sorgente)
• https://www.myget.org/gallery/aspnetvnext (dev NuGet ramo costruisce di quanto sopra)
• https://www.myget.org/gallery/aspnetmaster (branch master NuGet costruisce di quanto sopra [uguale alla tua domanda])

Questi le fonti sono gestite da Microsoft.

• L'attuale risorse Ninject on-line non menzionano

Come con qualsiasi nuovo sviluppo, 3rd fornitori biblioteca partito deve stabilire se stessi, quando (se non del tutto) che fornirà le implementazioni dei loro prodotti che supportano il nuovo codebase. Per alcuni, sarà più efficiente aspettare che il nuovo framework venga rilasciato ufficialmente, in quanto è probabile che le interruzioni dell'API possano verificarsi fino a quel momento. Il fatto che il supporto venga implementato è, naturalmente, fino alle risorse dei fornitori e/o nel caso di open source della comunità.

Answer 2

C'è una discussione in corso tra i manutentori delle librerie DI esistenti, se creare o meno, mantenere e supportare un adattatore per il nuovo sistema DI integrato di ASP.NET. I manutentori di Autofac hanno confirmed che creeranno e supporteranno un adattatore, mentre il team di Ninject è stato silent e altri team come il team di Simple Injector (che include me) have explained che non supporteranno un adattatore.

Personalmente, penso che la libreria DI di base di ASP.NET Core sia una libreria DI DI buona e pulita, ma limitata a semplici applicazioni. Come ho spiegato here, molte funzionalità necessarie per lo sviluppo di applicazioni gestibili basate sui principi SOLID non sono supportate. Tuttavia, proprio come la libreria Unity DI ha fatto un paio di anni fa, penso che questo contenitore integrato potrebbe effettivamente indurre gli sviluppatori a iniziare a utilizzare l'iniezione delle dipendenze, che è una vittoria per il nostro settore.

Queste limitazioni rendono il contenitore integrato particolarmente adatto per configurare ed estendere il sistema ASP.NET stesso. Per creare grandi applicazioni gestibili, è necessario utilizzare una diversa libreria DI. Questo naturalmente va bene; dovrai scegliere gli strumenti giusti per il lavoro.

Sfortunatamente, fino ad ora, il team di ASP.NET ha comunicato publicly che utilizzando una diversa libreria DI significa che si dovrà scrivere/utilizzare un adattatore. Questo purtroppo è il messaggio errato IMO, perché la maggior parte delle librerie DI è incompatibile con l'API presentata dal contenitore integrato (come ho spiegato nello specifico here e here). Solo Autofac sembra ragionevolmente sincronizzato, il che spiega perché il team di Autofac ha scelto di mantenere un adattatore. Ma notate che anche Autofac ha dimostrato di essere incompatibile con l'astrazione definita da Microsoft e che (proprio come StructureMap) hanno dovuto rendere big changes al loro prodotto per poter essere in grado di rispettare l'astrazione. E i manutentori di Autofac sono severely frustrated sull'intero processo e sull'astrazione in generale. E come ho spiegato here, anche l'implementazione dell'adattatore di Ninject fornita da ASP.NET è stata interrotta.

Questo messaggio dal team ASP.NET per utilizzare un adattatore è un errore IMO grave, perché questo soffoca l'innovazione (mentre la libreria DI stessa non lo è, è solo un'altra libreria DI). L'ASP.Il team di NET sta promuovendo un modello in cui i componenti dell'applicazione e il sistema ASP.NET (e tutti gli altri sottosistemi che verranno implementati in futuro) verranno registrati nel contenitore personalizzato. È molto più ragionevole e pratico mantenere la configurazione dell'applicazione separata dalla configurazione del sistema ASP.NET (come spiegato here).

Per questo motivo, trovo l'uso di un adattatore per qualsiasi contenitore piuttosto inutile. Come ho mostrato here è davvero facile collegare il proprio contenitore DI, mantenendolo completamente separato dalle registrazioni di ASP.NET. Ciò significa che non è necessario il supporto per Ninject per poter utilizzare in modo efficace Ninject su un progetto ASP.NET Core. L'unica cosa che Ninject deve fare è creare una versione compatibile con .NET Core (nel caso in cui il tuo prodotto debba funzionare su quella nuova piattaforma).

Quindi, in poche parole, non sono sicuro che il supporto 'si stia spegnendo', sebbene alcuni manutentori DI (come il team Simple Injector, e probabilmente anche Castle Windsor e Ninject) abbiano scelto di non costruire, mantenere e supporta un'implementazione dell'adattatore per ASP.NET Core, perché non è necessario, ed è solo nel modo.

UPDATE novembre 2016

Sono stato discussing some improvements a ASP.NET core con Microsoft per rendere più facile plug un contenitore che non hanno un adattatore (date un'occhiata al mio example repository e soprattutto al Startup.cs of the Ninject sample project), ma fino ad ora Microsoft sembra aver bloccato i progressi perché (come afferma Fowler) la loro "bias towards conforming containers [è] annebbiamento [la loro] visione".