Algo a considerar al implementar esto es usar el proyecto Microsoft.Extensions.DependencyInjection.Abstractions como la dependencia principal en la implementación en Maui. Al reducir la huella de Microsoft.Extensions.DependencyInjection para que solo se use en la creación del contenedor, permitirá que las bibliotecas y los marcos de terceros sean independientes del contenedor.

Esto permite a un desarrollador o marco la opción de usar un contenedor diferente al proporcionado por Maui. Al usar el proyecto de abstracciones, el trabajo requerido por el desarrollador o el marco es simplemente implementar las interfaces en el proyecto de abstracciones. Donde todo el código de Maui solo usará las interfaces. Esto proporcionará un punto de extensión masivo para todos mientras volvemos a trabajar cómo funciona la inyección de dependencia en la plataforma.

@ahoefling Sí, así es como Maui consumirá todo. La única pregunta es si necesitamos usar el contenedor ya implementado para la implementación predeterminada o lanzar el nuestro, que tiene una mentalidad un poco más móvil en cuanto al rendimiento.

@PureWeen La implementación del contenedor predeterminado actual funciona bien para dispositivos móviles. Sin embargo, el montón de dependencias que trae el constructor de host es asombroso.

@PureWeen ¡ Es genial escuchar esto!

Por lo que tengo entendido, el rendimiento del contenedor del proyecto de extensiones es bastante sólido. Recomendaría que comencemos con el contenedor predeterminado y podamos iterar si las pruebas de rendimiento no cumplen con nuestras expectativas. Reuní una pequeña muestra de código de lo que estaba pensando para manejar algunos de los puntos de extensión.

Esto nos permite intercambiar fácilmente el contenedor por desarrolladores, frameworks o la plataforma Maui si queremos usar un contenedor diferente.

Quizás el System.Maui.Application podría verse así:
`` c #
Aplicación de clase pública: Element, IResourcesProvider, IApplicationController, IElementConfiguration
{
contenedor público IServiceProvider {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 ¿podemos usar esto para permitir que las personas creen su propio IServiceProvider?

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

Eso es a lo que se enganchan cosas como AutoFac

Hasta donde tengo entendido, Host Builder proporciona una API enriquecida para agregar más dependencias predeterminadas, como cerrar la sesión. Donde mi código sugerido es mucho más sencillo. No creo que ninguno de los enfoques sea más "correcto" que el otro, ya que resuelven diferentes problemas con la inyección de dependencia.

Generador de host
Si queremos crear las opiniones de que el registro de la consola ocurrirá de cierta manera y digamos que HttpClientFactory funcionará de cierta manera, entonces el Host Builder probablemente será nuestra mejor opción.

Lean ServiceCollection
Si queremos que nuestro sistema DI sea lo más sencillo posible y dejar que el desarrollador de la aplicación decida qué funcionará para ellos y qué no, entonces creo que mi código sugerido o similar sería la forma de implementarlo.

La forma en que veo el problema es cuál es la forma menos invasiva de cambiar el DependencyService . Si el objetivo final es seguir los patrones establecidos con asp.net core y el modelo de generador de host, probablemente será mejor crear una clase Startup.cs que utilice el generador de host.

El código en el OP es problemático ya que no está claro por los tipos involucrados cómo funciona ServiceProvider.GetService<MainPage>() y cómo se descubre MainViewModel . También implica un null que debería activar una advertencia NRT. Todo esto parece una forma de eludir el sistema de tipos. ASP.Net no es un ejemplo brillante de una API limpia.

Es importante que los usuarios puedan evitar el uso de esta capacidad, como pueden hacerlo ahora, y especificar los objetos de forma segura. Y que al evitarlo, los usuarios también evitan pagar la penalización de rendimiento.

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

Si la gente quiere obtener un modelo de vista en una forma basada en reflexión / convención / anotación, ¿MAUI realmente necesita brindar apoyo explícito? ¿No pueden hacer esto de todos modos? El enlace original sugiere que pueden.

@ahoefling

Host Builder vs Lean ServiceCollection

Correcto, ¡descubrir el beneficio de uno frente al otro es definitivamente una gran parte de esto!

Al principio, solo miraba las colecciones de servicios ajustados, pero decidí ir con todo.
Parte de la ventaja de usar la dirección del constructor es que simplemente se vincula con las implementaciones de netcore existentes. Por ejemplo, con AutoFac puede usar la misma sintaxis de bucle de inicio en lugar de tener que inventar lo nuestro. El conocimiento del dominio es transferible.

@PureWeen Esto tiene sentido y es una buena idea para mantener la unificación de .NET 5+ y las habilidades transferibles entre las diferentes herramientas.

Creo que deberíamos crear un Startup.cs que se encuentra justo al lado del App.cs o App.xaml.cs que maneja todo el código de inicio. Esto unificará la historia de la inyección de dependencia en Maui con otros proyectos en el ecosistema .NET. Cuando implementé la inyección de dependencia en los módulos DNN el año pasado, hice algo similar que permitió a los desarrolladores transferir sus habilidades con bastante facilidad.

Creo que deberíamos crear un Startup.cs que se encuentra justo al lado de App.cs o App.xaml.cs que maneja todo el código de inicio.

Los nuevos usuarios no querrán descubrir todas estas cosas de arranque. En mi opinión, esto es lo último que desea, especialmente porque MAUI aliviará todo el texto estándar en torno a AppDelegate, MainActivity, etc. 1 inicio / app.xaml para gobernarlos a todos.

@aritchie estuvo de acuerdo

Me gustaría habilitar a las personas tanto como sea posible, pero para los nuevos usuarios, la mayor parte de esto puede permanecer oculto.
Pero luego, una vez que se sientan cómodos, pueden comenzar a extender las cosas.

Creo que hay escenarios aquí donde los usuarios pueden obtener ventajas aquí sin tener que comprar todo.

Por ejemplo, con Shell podríamos simplemente introducir una sintaxis de RegisterRoute como

Shell.RegisterRoute<TBindingContext, TPage>(String routeName);
o solo
Shell.RegisterRoute<TType>();

Que bajo el capó usa todas estas cosas para crear los tipos. Luego, si los usuarios quieren un HttpContext que se inyectará, etc.

La otra parte de esta propuesta es intentar crear todas las plantillas de datos a través de IServiceProvider, lo que permite algunos escenarios divertidos.

Estaba jugando con algunas variaciones con Shell aquí basadas en la muestra de James.

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

@charlesroddie

Si la gente quiere obtener un modelo de vista en una forma basada en reflexión / convención / anotación, ¿MAUI realmente necesita brindar apoyo explícito?

Actualmente, el plan no es proporcionar nada a través de la reflexión debido a consideraciones de rendimiento. Puede haber algunas áreas en las que podemos simplificar el registro sin afectar el rendimiento, pero aún necesitamos explorarlas.

También he actualizado el comentario original con la sintaxis de registro.

@PureWeen

Recomendaría tener algún tipo de extensiones de ruta fuera de IServiceCollection para que cosas como Prism se puedan agregar al modelo. He estado usando XF durante años y no uso Shell.

es decir. services.UseRoute(nombre opcional)

En otra nota, Shiny tiene una gran cantidad de uso en torno a la mecánica DI de Microsoft si necesita otras ideas. Terminé rechazando el modelo de hostbuilder (en su forma actual) debido a la cantidad de cosas que trajo y que llevaron a una pelea horrible con el enlazador. Estaría feliz de compartir estas experiencias en una llamada en algún momento.

¿Quizás los generadores de fuentes podrían usarse para aliviar los problemas de rendimiento? Entonces aún puede usar los atributos personalizados pero hacer todo el registro (predeterminado) en un archivo fuente generado.

¡@aritchie suena bien!

una vez que estemos del otro lado de la diversión de construir, ¡charlemos!

@rogihee

Quizás generadores de fuentes

¡¡Sí!! Queremos reestructurar el registro de renderizador actual antes de Maui y estamos buscando los generadores de origen para ese trabajo. Si terminamos yendo por esa ruta, definitivamente podríamos aprovechar eso para esto.

Sería genial tener DI en Xamarin Forms, pero no leo nada sobre los ámbitos de DI. El uso de ámbitos DI es una excelente manera de administrar la vida útil de los componentes. Es especialmente útil cuando se trabaja con contextos de base de datos de EF core.

Sería estupendo tener una implementación ICommand consciente de DI que cree un alcance y solicite un objeto controlador de comandos en este alcance.

El uso de la inyección de dependencia en las aplicaciones de WPF también es difícil, por lo que tal vez se asocie con el equipo de WPF para permitir el uso de DI en WPF de una manera similar.

La única pregunta es si necesitamos usar el contenedor ya implementado para la implementación predeterminada o lanzar el nuestro, que tiene una mentalidad un poco más móvil en cuanto al rendimiento.

Yo diría que implementar un contenedor para Maui desde cero. Como puede ver aquí , el DependecyService implementado en el Xamarin.Forms es el más rápido. (Lo sé ... Ese artículo es un poco antiguo, pero no creo que los valores cambien demasiado).
También es mucho mejor, en términos de rendimiento, crear nuestro propio contenedor DI. Pero mi preocupación es por un mundo sin .NET 5. Con .NET 5 y el generador de código fuente, podemos tener otra solución a este problema.
Y, para dispositivos móviles , si necesita una DI pesada, está haciendo algo mal.

Vine a este repositorio para proponer que las aplicaciones MAUI admitan el host genérico (Microsoft.Extensions.Hosting), preferible de forma predeterminada (aunque algunas personas pueden querer proteger), ya que es muy natural tener DI en una aplicación de interfaz de usuario. Significaría que la gente necesita entender menos, si están acostumbrados a la inyección de dependencia para el núcleo de asp.net, entonces también funcionará con MAUI. Para los principiantes, sería bueno mantener la configuración muy minimalista.

En lugar de ser el primero, encontré este problema y creo que es una buena discusión.

Tener aplicaciones que brindan algunos servicios y una pequeña interfaz de usuario (estado, configuración, etc.) sigue siendo algo común. Cada vez que creo una pequeña aplicación que proporciona algún servicio, sigo encontrando la necesidad de ampliarla con una interfaz de usuario.

Ya construí algo para que las aplicaciones de Windows Forms y WPF se ejecuten en el host genérico, como se puede ver en este proyecto: https://github.com/dapplo/Dapplo.Microsoft.Extensions.Hosting
Esperaba usar esto para Greenshot, pero todavía no he publicado nada con él.
En las muestras hay proyectos de WPF que utilizan ReactiveUI, MahApps y Caliburn.Micro.

Por favor, no me obligue a registrar las vistas manualmente en DI. Toma lo mejor de blazor, ¡es genial! En blazor puedo pasar parámetros fácilmente o inyectar el servicio en el componente. No es necesario registrar el componente por sí mismo. Solo necesito registrar los servicios. MVVM es excelente para las páginas, pero nunca me he sentido más productivo al crear estas vistas de componentes autohospedadas. Odio comenzar un nuevo proyecto de Xamarin, WPF, UWP debido a las cosas que no están disponibles de fábrica. Una vez más, mire Blazor, es un verdadero modelo para todos los futuros marcos de GUI.

No puedo entender por qué alguien alguna vez crearía estas dos declaraciones consecutivas:

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

¿Qué hay de malo en inyectar el servicio en el código de vistas que hay detrás? Es lo que quieres el 99,99% del tiempo.

También me gusta mucho la inyección de propiedades en blazor en lugar de la inyección de constructor, solo porque es más fácil.

De hecho, acabo de publicar una biblioteca que hace esto para Xamarin.Forms https://github.com/hostly-org/hostly . Utiliza una implementación personalizada de IHost, que se puede configurar fácilmente en los puntos de entrada nativos. por ejemplo, en MainActivity reemplazaría:

LoadApplication(new App());`

con:

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

también tiene algunas ventajas adicionales integradas como soporte para registrar middleware con navegación.

Estoy a favor de usar un sistema DI que esté fuera del espacio de nombres System.Maui para que el código se pueda compartir con proyectos MAUI y no MAUI.

Donde estoy menos seguro es con respecto al uso de Microsoft.Extensions.DependencyInjection o algo basado en él como ese sistema DI. No pretendo ser un experto en esto, ciertamente no he usado múltiples sistemas DI modernos. Sin embargo, me pregunto si otros han leído la segunda edición de “Inyección de dependencia. Principios, prácticas y patrones ”por Steven van Deursen y Mark Seemann. Dedican una sección en la segunda edición a analizar Autofac, Simple Injector y Microsoft.Extensions.DependencyInjection, proporcionando pros y contras, así como sus propias opiniones / conclusiones. Si bien puedo ver algunos beneficios de usar Microsoft.Extensions.DependencyInjection (principalmente que se usa en otros escenarios de Microsoft) en el mundo MAUI, me pregunto si alguien aquí con experiencia en múltiples sistemas DI podría comentar sobre las conclusiones de los autores y en qué medida ¿Se relacionan con el mundo MAUI del uso de dispositivos móviles y de escritorio?