Dependencyinjection: Schnittstelle, um zu formalisieren, wie Tools den Dienstanbieter der Anwendung erhalten

Ich verstehe nicht, was das mit DI zu tun hat. Suchen wir nur nach einem Ort, an dem wir eine Schnittstelle platzieren können?

Sicher, wo sollen wir es hinstellen?

Ehrlich gesagt verstehe ich nicht, was das löst ... Werden wir gemeinsam genutzten Code haben, der diese Schnittstelle oder so etwas aufruft?

Nicht unbedingt, aber ja, wir könnten.

Wie der Titel sagt und die Beschreibung hoffentlich erklärt, formalisiert diese Schnittstelle die Konvention, die Tools implementieren müssen, um den Dienstanbieter der Anwendung zur Entwurfszeit zu erhalten. ZB anstatt einen Host vorzutäuschen und Startup zu instanziieren, um ConfigureServices() basierend auf den Templates von gestern aufzurufen, rufen wir Program.BuildWebHost() basierend auf den Templates von morgen auf, was auch immer uns in der Zukunft einfällt oder wie auch immer Wenn sich Kunden entscheiden, ihren Code zu faktorisieren, legen wir fest, dass Tools nach einem Typ suchen, der diese Schnittstelle im Startprojekt implementiert, und wir fangen an, standardmäßig einen in die Vorlagen aufzunehmen.

Die Hauptaffinität zu DI besteht darin, dass es darum geht, die IServiceProvider zu erhalten. Ich denke, es könnte stattdessen in ein Tooling-Abstraktionspaket gehen, wenn wir so etwas hätten.

Es ist auch eine interessante Idee für Universal-Apps. Es besteht immer das Problem, dass ViewModels zur Entwurfszeit nicht instanziiert werden können, die Konstruktorargumente haben, die zur Laufzeit von DI kommen sollen. Jeder versucht, eine Lösung zu finden, und sie ist nicht immer hübsch. Manchmal sind sie schrecklich. Hier geht es nicht um „Werkzeuge“ an sich, nicht im Sinne von .NET Core, aber wie cool wäre es, wenn XDesProc dies verwenden könnte? Nun, in Phase eins würde ich dies mit if (DesignModeEnabled) verwenden ...

@divega @davidfowl @ajcvickers @DamianEdwards @muratg @bricelam – wie ist der Stand davon? Wir haben uns letzte Woche getroffen, und ich dachte, wir sind vielleicht zu einem Ergebnis gekommen, aber ich erinnere mich nicht an die konkreten nächsten Schritte. Wie auch immer wir uns entscheiden, wir sollten versuchen, es in dieser Woche zu bekommen.

@Eilon Diego, Brice und ich haben vor einer Weile darüber gesprochen. Brice wird einige Pull-Requests senden und wir werden es von dort aus übernehmen.

Können Sie etwas dazu sagen, einige UI-Leute an Bord zu holen? Xamarin, UWP? Sehen Sie darin einen Vorteil? Oder sollte ich dieses Problem an ein paar anderen Stellen ansprechen?

@ericwj Es lohnt sich an den jeweiligen Stellen zu erhöhen.

Ich denke, es ist mit MVVM etwas weniger interessant, da die meisten Leute dort wahrscheinlich nicht Microsoft.Extensions.DependencyInjection.Abstraction verwenden, wie wir es in ASP.NET Core tun.

Nein, nicht heute, aber siehe da, .NET Standard kommt. Ich glaube nicht, dass ein Datum für UWP 2.0 erwähnt wird, aber sobald es da ist, wird es ziemlich viel bewirken, da bin ich mir sicher. Das Teilen von Grundlagen wie diesem beseitigt Reibungspunkte und macht den Wechsel von Projekttypen weniger zu einem Kulturschock. Und es wäre sowieso ein Opt-in, da bin ich mir sicher ...

Ich habe versucht, ein geeignetes Repo für XAML zu finden, aber ich konnte nicht wirklich eines finden. Können Sie mich irgendwo weiterleiten, oder sollte ich Provide a suggestion... von VS verwenden und es unter https://visualstudio.uservoice.com posten?

VS Feedback wäre ein guter Ausgangspunkt. Vielleicht würde dotnet/project-system auch die richtigen Leute dazu bringen, es sich anzusehen.

Und Xamarin? Sie haben keine Probleme. Nur Pull-Requests 🥇

Sorry, keine Ahnung davon

TY sowieso, ich werde es schaffen

Meilenstein aufräumen, damit dieser erneut überprüft werden kann. Wir planen nicht, dies für 2.0.0 zu tun. Auch einige relevante Kommentare im Gespräch über die PR: https://github.com/aspnet/DependencyInjection/pull/527#issuecomment -302557915.

@divega In welchen Meilenstein sollte das gehen? 2.2 oder Rückstand?

@muratg Ich denke, es ist in Ordnung, dass dies im Rückstand ist. Es scheint immer noch nett zu sein, und von Zeit zu Zeit hören wir von Leuten, die etwas wollen, das mit DI ohne ASP.NET Core und ohne den ganzen Weg nach unten zu IDesignTimeDbContextFactory funktioniert, aber es scheint keine hohe Priorität zu haben .

Cc @bricelam und @ajcvickers , falls sie denken, wir sollten planen, es früher zu haben.

Dieses Problem wurde nach aspnet/Home#2342 verschoben