Fortsetzung Ninject-Unterstützung in ASP.NET MVC 6?

Question

Ich bin seit langem sehr glücklich mit Ninject, und ich mag es wirklich, aber ich bin mit einer schwierigen Wahl seit der Veröffentlichung von ASP.NET 5 und MVC 6 konfrontiert.

Im Grunde genommen hat Microsoft ein eigenes Dependency-Injection-System offengelegt; Welches ist eines, das meines Wissens eine Menge Kritik bekommen hat. Aber mein größeres Problem liegt darin, wie es sich auf andere Bibliotheken auswirkt.

Von another question I asked und other resources online scheint es, dass Ninject nicht mit MVC 6. aus der Box funktioniert Obwohl es eine „Lösung“ Microsoft.Framework.DependencyInjection.Ninject and Ninject in Form einer ausführlichen Bibliothek gegeben ist. Dies ist noch komplizierter, da diese Bibliothek das Hinzufügen von https://www.myget.org/F/aspnetmaster/ zu Ihrer Liste von NuGet Feeds erfordert.

Ich habe etwas gegraben und gefunden, wo diese Bibliothek gehostet wird; Es sieht gut aus, es scheint in Ordnung zu sein, was ich sagen kann, aber es gibt ein paar Dinge, die mich beunruhigen.

• Die Bibliothek nicht wirklich erscheinen von den Ninject Schöpfer geleitet werden
• Die Bibliothek begraben liegt ziemlich tief in einem dunklen Repository
• Die tatsächlichen Ninject Ressourcen online nie erwähnen

So Grundsätzlich bin ich sehr besorgt, dass dies eine Art Band-Helfer ist, und dass die Unterstützung für Ninject (und sogar andere Container-Bibliotheken) aussterben wird. Gibt es versteckte Informationen, die ich gerade nicht entdeckt habe?

Answer 1

• Die Bibliothek erscheint nicht wirklich von den

dieser Bibliothek Schöpfer Ninject geleitet zu werden, und es würde these also, aussehen scheinen Microsoft Proben erstellt Injection Anbieter von Abhängigkeit sein, dass waren removed in beta7. Beachten Sie, dass der Link zu , auf den sich Ihre original question bezieht, Folgendes sagt;

Diese DI-Containeradapter sind temporär und dienen als Referenz; wir erwarten, dass sie irgendwann entfernt werden und durch die entsprechenden Containerbesitzer ersetzt werden.

Wie sie sein sollten. Microsoft sollte nicht für die Wartung von Drittanbieter verantwortlich sein.

• Die Bibliothek in einem obskuren Repository ziemlich tief
begraben liegt

Wenn Sie nicht wissen, 5 ASP.NET ist noch in der Entwicklung.Beta 7 ist auf Nuget als Vorabversion verfügbar, aber es gibt auch andere Quellen;

• https://github.com/aspnet/ (Quellcode)
• https://www.myget.org/gallery/aspnetvnext (nuget dev Zweig der oben Builds)
• https://www.myget.org/gallery/aspnetmaster (nuget Master Zweig baut der oben [wie Ihre Frage gleiche])

These Quellen werden von Microsoft verwaltet.

• Die tatsächlichen Ninject Ressourcen online nie mit jeder neuen Entwicklung, 3rd-Party-Bibliothek-Anbieter müssen sich bestimmen, wann (wenn überhaupt)

Wie nennen sie Implementierungen ihrer Produkte zur Verfügung stellt die die neue Codebasis unterstützen. Für einige wird es als am effizientesten angesehen, zu warten, bis das neue Framework offiziell freigegeben wird, da API-Unterbrechungsänderungen mit hoher Wahrscheinlichkeit bis zu diesem Zeitpunkt auftreten. Ob Unterstützung überhaupt implementiert wird, hängt natürlich von den Ressourcen des Anbieters und/oder im Falle von Open Source der Community ab.

Answer 2

Es gibt eine Diskussion zwischen Betreuern der vorhandenen DI-Bibliotheken, unabhängig davon, ob ein Adapter für das neue integrierte DI-System von ASP.NET erstellt, gewartet und unterstützt wird. Die Autofac-Betreuer haben confirmed, dass sie einen Adapter erstellen und unterstützen werden, während das Ninject-Team silent ist, und andere Teams wie das Simple Injector-Team (das mich einschließt), dass sie keinen Adapter unterstützen.

Persönlich denke ich, dass die integrierte DI-Bibliothek von ASP.NET Core eine schöne und saubere DI-Bibliothek ist, aber es ist auf einfache Anwendungen beschränkt. Wie ich erklärt here, werden viele Funktionen, die für die Entwicklung wartbarer Anwendungen auf der Grundlage der SOLID-Prinzipien erforderlich sind, nicht unterstützt. Genau wie die Unity DI-Bibliothek vor ein paar Jahren, denke ich, dass dieser integrierte Container Entwickler dazu bringen könnte, die Abhängigkeitsinjektion zu verwenden, was für unsere Branche ein Gewinn ist.

Diese Einschränkungen machen den integrierten Container besonders geeignet, das ASP.NET-System selbst zu konfigurieren und zu erweitern. Um große wartbare Anwendungen zu erstellen, müssen Sie eine andere DI-Bibliothek verwenden. Das ist natürlich in Ordnung; Sie müssen die richtigen Werkzeuge für den Job auswählen.

Leider hat das ASP.NET-Team bisher publicly mit einer anderen DI-Bibliothek kommuniziert, dh Sie müssen einen Adapter schreiben/verwenden. Dies ist leider die falsche IMO-Nachricht, da die meisten DI-Bibliotheken nicht mit der API kompatibel sind, die durch den integrierten Container dargestellt wird (wie ich ausführlich here und here erklärt habe). Nur Autofac scheint einigermaßen synchron zu sein, weshalb sich das Autofac-Team für die Wartung eines Adapters entscheidet. Beachten Sie jedoch, dass selbst Autofac sich als nicht kompatibel mit der von Microsoft definierten Abstraktion erwiesen hat und sie (ebenso wie StructureMap) big changes zu ihrem Produkt machen mussten, um die Abstraktion sogar einhalten zu können. Und die Autofac-Betreuer sind severely frustrated über den gesamten Prozess und die Abstraktion im Allgemeinen. Und wie ich here erklärte, ist sogar die von ASP.NET zur Verfügung gestellte Adapter-Implementierung von Ninject gebrochen.

Diese Nachricht vom ASP.NET-Team, einen Adapter zu verwenden, ist IMO ein großer Fehler, weil dies Innovation erstickt (während die DI-Bibliothek selbst nicht; es ist nur eine andere DI-Bibliothek). Der ASP.Das NET-Team bewirbt ein Modell, bei dem sowohl Ihre Anwendungskomponenten als auch das ASP.NET-System (und alle anderen Subsysteme, die zukünftig plugged werden) in Ihrem benutzerdefinierten Container registriert werden. Es ist viel sinnvoller und praktischer, Ihre Anwendungskonfiguration getrennt von der Konfiguration des ASP.NET-Systems zu halten (wie erläutert here).

Aus diesem Grund finde ich die Verwendung eines Adapters für jeden Container eher nutzlos. Wie ich gezeigt habe here ist es wirklich einfach, Ihren eigenen DI-Container zu pluginieren, während es völlig getrennt von ASP.NET-Registrierungen bleibt. Dies bedeutet, dass Sie keine Unterstützung für Ninject benötigen, um Ninject effektiv für ein ASP.NET Core-Projekt verwenden zu können. Das einzige, was Ninject tun muss, ist eine Version zu erstellen, die mit .NET Core kompatibel ist (falls Ihr Produkt auf dieser neuen Plattform laufen muss).

Also bin ich mir nicht sicher, ob die Unterstützung "aussterben", obwohl einige DI-Betreuer (wie das Simple Injector-Team und wahrscheinlich auch Castle Windsor und Ninject) beschlossen haben, nicht zu bauen und zu warten und unterstützen eine Adapterimplementierung für ASP.NET Core, da sie nicht benötigt wird und nur im Weg ist.

UPDATE November 2016

Ich habe discussing some improvements zu ASP.NET-Core mit Microsoft ist es einfacher zu machen, einen Behälter-Plugin, das einen Blick auf meinem example repository keinen Adapter hat (nehmen und vor allem, um die Startup.cs of the Ninject sample project), aber bis jetzt scheint Microsoft den Fortschritt zu blockieren, weil (wie Fowler sich selbst behauptet) ihre "bias towards conforming containers [ist] Clouding [ihre] Vision".