Bei der Implementierung ist zu beachten, dass das Projekt Microsoft.Extensions.DependencyInjection.Abstractions als Hauptabhängigkeit der Implementierung in Maui verwendet wird. Durch die Reduzierung des Platzbedarfs von Microsoft.Extensions.DependencyInjection , der nur beim Erstellen des Containers verwendet wird, können Bibliotheken und Frameworks von Drittanbietern unabhängig vom Container sein.

Dies ermöglicht einem Entwickler oder Framework die Möglichkeit, einen anderen Container als den von Maui bereitgestellten zu verwenden. Durch die Verwendung des Abstraktionsprojekts besteht die vom Entwickler oder Framework benötigte Arbeit lediglich darin, die Schnittstellen im Abstraktionsprojekt zu implementieren. Wo der gesamte Maui-Code nur die Schnittstellen verwendet. Dies wird einen massiven Erweiterungspunkt für alle bieten, während wir die Funktionsweise von Dependency Injection in der Plattform überarbeiten.

@ahoefling Ja, so wird Maui alles konsumieren. Die Frage ist nur, ob wir den bereits implementierten Container für die Standardimplementierung verwenden oder unseren eigenen, der in Bezug auf die Leistung etwas mobiler ist, verwenden müssen

@PureWeen Die aktuelle Standardcontainerimplementierung

@PureWeen das ist toll zu hören!

Soweit ich weiß, ist die Leistung des Erweiterungsprojektcontainers ziemlich solide. Ich würde empfehlen, mit dem Standardcontainer zu beginnen und iterieren zu können, wenn Leistungstests nicht unseren Erwartungen entsprechen. Ich habe ein kleines Codebeispiel von dem zusammengestellt, was ich dachte, um einige der Erweiterungspunkte zu handhaben.

Dadurch können wir den Container einfach von Entwicklern, Frameworks oder der Maui-Plattform austauschen, wenn wir einen anderen Container verwenden möchten.

Vielleicht könnte das System.Maui.Application so aussehen:
```c#
öffentliche Klasse Anwendung: Element, IResourcesProvider, IApplicationController, IElementConfiguration
{
öffentlicher IServiceProvider-Container { get; }

protected virtual IServiceProvider CreateContainer()
{
    var serviceCollection = new ServiceCollection();
    RegisterDependencies(serviceCollection);
    return serviceCollection.BuildServiceProvider();
}

// This should be implemented in the app code
protected virtual void RegisterDependencies(IServiceCollection serviceCollection)
{
    // TODO - Register dependencies in app code
}

public Application()
{
    Container = CreateContainer();

    // omited code
}

// omitted code

}
```

@ahoefling können wir dies verwenden, um es den Leuten zu ermöglichen, ihren eigenen IServiceProvider zu erstellen?

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.hosting.hostbuilder.useserviceproviderfactory?view=dotnet-plat-ext-3.1

Daran hängen Dinge wie AutoFac

Soweit ich weiß, bietet der Host Builder eine umfangreiche API, um weitere Standardabhängigkeiten wie das Abmelden von der Box hinzuzufügen. Wobei mein vorgeschlagener Code viel schlanker ist. Ich glaube nicht, dass einer der Ansätze "richtiger" ist als der andere, da sie verschiedene Probleme mit Dependency Injection lösen.

Host-Builder
Wenn wir die Meinung schaffen möchten, dass die Konsolenprotokollierung auf eine bestimmte Weise erfolgt und sagen wir, dass HttpClientFactory auf eine bestimmte Weise funktioniert, dann ist der Host Builder wahrscheinlich unsere beste Option.

Lean ServiceCollection
Wenn wir möchten, dass unser DI-System so schlank wie möglich ist und der App-Entwickler entscheiden lässt, was für ihn funktioniert und was nicht, dann denke ich, dass mein vorgeschlagener Code oder ähnlicher der Weg wäre, es zu implementieren.

Die Art und Weise, wie ich das Problem betrachte, ist der am wenigsten invasive Weg, um das DependencyService . Wenn das Endziel darin besteht, den Mustern von asp.net core und dem Host-Builder-Modell zu folgen, ist es wahrscheinlich am besten, eine Startup.cs Klasse zu erstellen, die den Host-Builder verwendet.

Der Code im OP ist problematisch, da aus den beteiligten Typen unklar ist, wie ServiceProvider.GetService<MainPage>() funktioniert und wie MainViewModel entdeckt wird. Es beinhaltet auch ein null das eine NRT-Warnung auslösen sollte. Dies alles scheint eine Möglichkeit zu sein, das Typensystem zu umgehen. ASP.Net ist kein leuchtendes Beispiel für eine saubere API.

Es ist wichtig, dass Benutzer in der Lage sein sollten, diese Funktion zu vermeiden, wie sie es jetzt können, und die Objekte auf typsichere Weise angeben. Und durch die Vermeidung vermeiden Benutzer auch die Zahlung der Leistungseinbußen.

type App() =
    inherit Application()
    let vm = someMainViewModel(...)
    let mainPage = MainPage(vm)
    do  base.MainPage <- mainPage

Wenn Leute ein Ansichtsmodell auf Reflexions-/Konventions-/Anmerkungsbasis erhalten möchten, muss MAUI dann wirklich explizite Unterstützung bieten? Können sie das nicht trotzdem? Der ursprüngliche Link deutet darauf hin, dass sie es können.

@ahoefling

Host Builder vs. Lean ServiceCollection

Richtig, den Vorteil des einen gegenüber dem anderen herauszufinden, ist definitiv ein großer Teil davon!

Zuerst habe ich mir nur Lean Service Collections angesehen, aber beschlossen, alles zu tun.
Ein Teil des Vorteils der Verwendung der Builder-Richtung besteht darin, dass sie nur an vorhandene Netcore-Implementierungen anknüpft. Zum Beispiel können Sie mit AutoFac einfach die gleiche Startup-Schleifensyntax verwenden, anstatt unser eigenes Ding erfinden zu müssen. Das Domänenwissen ist übertragbar.

@PureWeen Dies ist sinnvoll und eine gute Idee, um die Vereinheitlichung von .NET 5+ und die übertragbaren Fähigkeiten zwischen den verschiedenen Tools

Ich denke, wir sollten ein Startup.cs erstellen, das sich direkt neben dem App.cs oder App.xaml.cs , das den gesamten Startcode verarbeitet. Dadurch wird die Dependency Injection-Story in Maui mit anderen Projekten im .NET-Ökosystem vereinheitlicht. Als ich letztes Jahr Dependency Injection in DNN-Module implementierte, tat ich etwas Ähnliches, was es Entwicklern ermöglichte, ihre Fähigkeiten ganz einfach zu übertragen.

Ich denke, wir sollten eine Startup.cs erstellen, die sich direkt neben App.cs oder App.xaml.cs befindet, die den gesamten Startcode verarbeitet.

Neue Benutzer werden nicht all diese Bootstrapping-Sachen herausfinden wollen. Meiner Meinung nach ist dies das Letzte, was Sie wollen, zumal MAUI den gesamten Boilerplate rund um AppDelegate, MainActivity usw. 1 startup/app.xaml abmildert, um sie alle zu beherrschen.

@aritchie hat zugestimmt

Ich möchte den Leuten so viel wie möglich ermöglichen, aber für neue Benutzer kann das meiste davon einfach verborgen bleiben.
Aber sobald sie sich wohl fühlen, können sie damit beginnen, die Dinge zu erweitern.

Ich denke, es gibt hier Szenarien, in denen Benutzer hier Vorteile erzielen können, ohne sich in alles einkaufen zu müssen.

Zum Beispiel könnten wir mit Shell einfach eine RegisterRoute-Syntax einführen wie

Shell.RegisterRoute<TBindingContext, TPage>(String routeName);
oder nur
Shell.RegisterRoute<TType>();

Das unter der Haube verwendet all dieses Zeug, um die Typen zu erstellen. Wenn Benutzer dann einen HttpContext wünschen, der in usw. injiziert wird.

Der andere Teil dieses Vorschlags besteht darin, alle DataTemplates auch über den IServiceProvider zu erstellen, was einige lustige Szenarien ermöglicht.

Ich habe hier mit einigen Variationen mit Shell gespielt, die auf James' Sample basieren

https://github.com/PureWeen/AllExtensions-DI-IoC/tree/shell_ioc

@charlesroddie

Wenn Leute ein Ansichtsmodell auf Reflexions-/Konventions-/Anmerkungsbasis erhalten möchten, muss MAUI dann wirklich explizite Unterstützung bieten?

Aus Leistungsgründen ist derzeit nicht geplant, durch Reflexion etwas bereitzustellen. Es mag einige Bereiche geben, in denen wir die Registrierung ohne Leistungseinbußen vereinfachen können, diese aber noch untersuchen müssen.

Ich habe auch den ursprünglichen Kommentar mit der Registrierungssyntax aktualisiert

@PureWeen

Ich würde empfehlen, einige Routenerweiterungen aus der IServiceCollection zu haben, damit Dinge wie Prism in das Modell eingesteckt werden können. Ich benutze XF seit Jahren und ich benutze keine Shell.

dh. services.UseRoute(optionaler Name)

Außerdem wird Shiny in großem Umfang rund um die Microsoft DI-Mechanik verwendet, wenn Sie andere Ideen benötigen. Am Ende habe ich das Hostbuilder-Modell (in seiner jetzigen Form) abgelehnt, weil es so viele Dinge gebracht hat, die zu einem schrecklichen Kampf mit dem Linker führten. Diese Erfahrungen teile ich gerne irgendwann bei einem Anruf mit.

Vielleicht könnten Quellgeneratoren verwendet werden, um die Leistungsprobleme zu lindern? Dann können Sie immer noch die benutzerdefinierten Attribute verwenden, aber die (Standard-)Registrierung in einer generierten Quelldatei durchführen.

@aritchie hört sich gut an!

Sobald wir auf der anderen Seite des Bauspaßes sind, lass uns chatten!

@rogihee

Vielleicht Quellgeneratoren

Ja!! Wir wollen die aktuelle Renderer-Registrierung vor Maui umstrukturieren und schauen uns die Source Generators für diese Arbeit an. Wenn wir am Ende diesen Weg gehen, könnten wir das definitiv dafür nutzen

Wäre toll, DI in Xamarin Forms zu haben, aber ich lese nichts über DI-Bereiche. Die Verwendung von DI-Bereichen ist eine großartige Möglichkeit, die Lebensdauer von Komponenten zu verwalten. Dies ist besonders nützlich, wenn Sie mit den Datenbankkontexten von EF Core arbeiten.

Es wäre großartig, eine DI-fähige ICommand Implementierung zu haben, die einen Bereich erstellt und ein Befehlshandlerobjekt für diesen Bereich anfordert.

Die Verwendung von Dependency Injection in WPF-Anwendungen ist ebenfalls schwierig. Arbeiten Sie daher möglicherweise mit dem WPF-Team zusammen, um die Verwendung von DI in WPF auf ähnliche Weise zu ermöglichen.

Die Frage ist nur, ob wir den bereits implementierten Container für die Standardimplementierung verwenden oder unseren eigenen, der in Bezug auf die Leistung etwas mobiler ist, verwenden müssen

Ich würde sagen, einen Container für die Maui von Grund auf zu implementieren. Wie Sie hier sehen können , ist das in DependecyService implementierte Xamarin.Forms das schnellere. (Ich weiß ... Dieser Artikel ist ein wenig alt, aber ich glaube nicht, dass sich die Werte zu sehr ändern).
Außerdem ist es - in Bezug auf die Leistung - viel besser, einen eigenen DI-Container zu erstellen. Aber meine Bedenken gelten einer Welt ohne .NET 5. Mit .NET 5 und dem Quellcode-Generator haben wir möglicherweise eine andere Lösung für dieses Problem.
Und für Mobilgeräte , wenn Sie eine schwere DI benötigen, machen Sie etwas falsch.

Ich bin zu diesem Repository gekommen, um vorzuschlagen, dass MAUI-Anwendungen den generischen Host (Microsoft.Extensions.Hosting) unterstützen, vorzugsweise standardmäßig (obwohl einige Leute schützen möchten), da es sehr natürlich ist, DI in einer UI-Anwendung zu haben. Es würde bedeuten, dass die Leute weniger verstehen müssen, wenn sie an Dependency Injection für asp.net core gewöhnt sind, als es auch mit MAUI funktioniert. Für Anfänger kann es gut sein, die Konfiguration sehr minimalistisch zu halten.

Anstatt der Erste zu sein, habe ich dieses Problem gefunden und denke, es ist eine gute Diskussion!

Es ist immer noch üblich, Anwendungen zu haben, die einige Dienste und eine kleine Benutzeroberfläche (Status, Konfiguration usw.) bereitstellen. Jedes Mal, wenn ich eine kleine Anwendung erstelle, die einen Service bietet, stelle ich fest, dass dies um eine Benutzeroberfläche erweitert werden muss.

Ich habe bereits etwas erstellt, um Windows Forms- und WPF-Anwendungen auf dem generischen Host auszuführen, wie in diesem Projekt zu sehen ist: https://github.com/dapplo/Dapplo.Microsoft.Extensions.Hosting
Ich hatte gehofft, dies für Greenshot zu verwenden, aber derzeit habe ich noch nichts damit veröffentlicht.
In den Beispielen sind WPF-Projekte enthalten, die ReactiveUI, MahApps und Caliburn.Micro verwenden.

Bitte zwingen Sie mich nicht, die Ansichten manuell in DI zu registrieren. Nimm das Beste von blazor, es ist großartig! In blazor kann ich problemlos Parameter übergeben oder den Dienst in die Komponente einfügen. Es ist nicht erforderlich, die Komponente selbst zu registrieren. Ich muss nur die Dienste registrieren. MVVM ist großartig für Seiten, aber ich habe mich noch nie so produktiv gefühlt, diese selbst gehosteten Komponentenansichten zu erstellen. Ich hasse es, ein neues Xamarin-, WPF-, UWP-Projekt zu starten, da die Dinge nicht standardmäßig vorhanden sind. Schauen Sie sich noch einmal Blazor an, es ist eine wahre Blaupause für alle zukünftigen GUI-Frameworks.

Ich kann nicht verstehen, warum jemals jemand diese beiden konkutanen Aussagen erstellen würde:

    services.AddTransient<IMainViewModel, MainViewModel>();
    services.AddTransient<MainPage>();

Was ist falsch daran, den Dienst in den View-Code dahinter zu injizieren? Es ist das, was Sie zu 99,99 % der Zeit wollen.

Auch gefällt mir die Property Injection in Blazor sehr gut, statt der Constructor Injection, nur weil es einfacher ist.

Ich habe gerade eine Bibliothek veröffentlicht, die dies für Xamarin.Forms https://github.com/hostly-org/hostly tut. Es verwendet eine benutzerdefinierte Implementierung von IHost, die einfach in den nativen Einstiegspunkten eingerichtet werden kann. zB in MainActivity würden Sie ersetzen:

LoadApplication(new App());`

mit:

new XamarinHostBuilder().UseApplication<App>()
   .UseStartup<Startup>()
   .UsePlatform(this)
   .Start();

Es hat auch einige zusätzliche Extras eingebaut, wie die Unterstützung für die Registrierung von Middleware bei der Navigation.

Ich bin dafür, ein DI-System zu verwenden, das sich außerhalb des System.Maui-Namespace befindet, damit Code sowohl für MAUI- als auch für Nicht-MAUI-Projekte freigegeben werden kann.

Wo ich mir weniger sicher bin, ist die Verwendung von Microsoft.Extensions.DependencyInjection oder etwas darauf basierendes DI-System. Ich will nicht vorgeben, ein Experte dafür zu sein – ich habe sicherlich selbst nicht mehrere moderne DI-Systeme verwendet. Ich frage mich jedoch, ob andere die zweite Ausgabe von „Dependency Injection. Prinzipien, Praktiken und Muster“ von Steven van Deursen und Mark Seemann. Sie widmen einen Abschnitt in der zweiten Auflage der Betrachtung von Autofac, Simple Injector und Microsoft.Extensions.DependencyInjection und liefern Vor- und Nachteile sowie ihre eigenen Meinungen/Schlussfolgerungen. Während ich einige Vorteile der Verwendung von Microsoft.Extensions.DependencyInjection (hauptsächlich, dass es in anderen Microsoft-Szenarien verwendet wird) in der MAUI-Welt sehen kann, frage ich mich, ob hier jemand mit Erfahrung mit mehreren DI-Systemen die Schlussfolgerungen der Autoren kommentieren könnte und in welchem ​​​​Ausmaß beziehen sie sich auf die MAUI-Welt der mobilen und Desktop-Nutzung?