이것을 구현할 때 고려해야 할 사항은 Microsoft.Extensions.DependencyInjection.Abstractions 프로젝트를 Maui 구현 전반에 걸쳐 주요 종속성으로 사용하는 것입니다. 컨테이너 생성에만 사용되도록 Microsoft.Extensions.DependencyInjection 의 공간을 줄임으로써 타사 라이브러리 및 프레임워크가 컨테이너에 대해 독립적으로 사용할 수 있습니다.

이를 통해 개발자 또는 프레임워크가 Maui에서 제공하는 것과 다른 컨테이너를 사용할 수 있습니다. 추상화 프로젝트를 사용하여 개발자 또는 프레임워크에 필요한 작업은 추상화 프로젝트에서 인터페이스를 구현하는 것입니다. 모든 마우이 코드는 인터페이스만 사용합니다. 이는 플랫폼에서 종속성 주입이 작동하는 방식을 재작업할 때 모든 사람에게 대규모 확장 지점을 제공합니다.

@ahoefling 그렇습니다 . 마우이가 모든 것을 소비하는 방식입니다. 유일한 질문은 기본 구현을 위해 이미 구현된 컨테이너를 사용해야 하는지 아니면 성능 면에서 조금 더 모바일 지향적인 자체 컨테이너를 롤링해야 하는지 여부입니다.

@PureWeen 현재 기본 컨테이너 구현은 모바일에서 잘 작동합니다. 하지만 호스트 빌더가 가져오는 종속성 덩어리는 어마어마합니다.

@PureWeen 정말 잘 듣습니다!

내가 이해하는 한 확장 프로젝트 컨테이너 성능은 꽤 견고합니다. 기본 컨테이너로 시작하고 성능 테스트가 기대에 미치지 못하는 경우 반복할 수 있도록 권장합니다. 일부 확장 지점을 처리하기 위해 생각했던 것에 대한 작은 코드 샘플을 작성했습니다.

이를 통해 다른 컨테이너를 사용하려는 경우 개발자, 프레임워크 또는 Maui 플랫폼에서 컨테이너를 쉽게 교체할 수 있습니다.

System.Maui.Application 는 다음과 같이 보일 수 있습니다.
```c#
public class Application : Element, IResourcesProvider, IApplicationController, IElementConfiguration
{
공개 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 이것을 사용하여 사람들이 자신의 IServiceProvider를 만들 수 있습니까?

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

AutoFac과 같은 것들이 연결되는 것입니다.

내가 이해하는 한 Host Builder는 로그아웃과 같은 기본 종속성을 추가할 수 있는 풍부한 API를 제공합니다. 내 제안된 코드가 훨씬 더 간결합니다. 나는 의존성 주입으로 다른 문제를 해결하기 때문에 두 접근 방식이 다른 것보다 더 '올바른' 것이라고 생각하지 않습니다.

호스트 빌더
콘솔 로깅이 특정 방식으로 발생하고 HttpClientFactory가 Host Builder보다 특정 방식으로 작동할 것이라는 의견을 만들고 싶다면 아마도 최선의 선택이 될 것입니다.

린 서비스 컬렉션
DI 시스템이 가능한 한 간결하고 앱 개발자가 자신에게 맞는 것과 그렇지 않은 것을 결정하게 하려면 제가 제안한 코드 또는 이와 유사한 것이 구현 방법일 것입니다.

내가 문제를 바라보는 방식은 DependencyService 를 교체하는 가장 덜 침습적인 방법입니다. 최종 목표가 asp.net 코어 및 호스트 빌더 모델의 패턴을 따르는 것이라면 호스트 빌더를 활용하는 Startup.cs 클래스를 만드는 것이 가장 좋습니다.

OP의 코드는 ServiceProvider.GetService<MainPage>() 작동하는 방식과 MainViewModel 가 발견되는 방식과 관련된 유형이 불분명하기 때문에 문제가 있습니다. 또한 NRT 경고를 트리거해야 하는 null 도 포함됩니다. 이 모든 것이 유형 시스템을 우회하는 방법처럼 보입니다. ASP.Net은 깨끗한 API의 빛나는 예가 아닙니다.

사용자가 지금처럼 이 기능의 사용을 피하고 유형이 안전한 방식으로 개체를 지정할 수 있어야 하는 것이 중요합니다. 이를 피함으로써 사용자는 성능 패널티를 지불하지 않아도 됩니다.

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

사람들이 리플렉션/컨벤션/주석 기반 방식으로 뷰 모델을 얻으려면 MAUI가 정말 명시적인 지원을 제공해야 합니까? 어쨌든 그들은 이것을 할 수 없습니까? 원래 링크 는 그들이 할 수 있다고 제안합니다.

@아호플링

호스트 빌더 대 린 ServiceCollection

맞습니다. 둘 중 하나의 이점을 파악하는 것은 확실히 이것의 큰 부분입니다!

처음에는 Lean Service Collections만 보고 있었지만 올인하기로 결정했습니다.
빌더 방향을 사용하는 이점 중 일부는 기존 넷코어 구현과 연결된다는 것입니다. 예를 들어 AutoFac을 사용하면 우리 자신의 것을 발명해야 하는 것과 반대로 동일한 시작 루프 구문을 사용할 수 있습니다. 도메인 지식은 양도 가능합니다.

@PureWeen 이것은 의미가 있으며 .NET 5+의 통합과 다른 도구 간의 이전 가능한 기술을 유지하는 것이 좋습니다.

모든 시작 코드를 처리하는 App.cs 또는 App.xaml.cs 바로 옆에 있는 Startup.cs 를 만들어야 한다고 생각합니다. 이것은 마우이의 의존성 주입 이야기를 .NET 생태계의 다른 프로젝트와 통합할 것입니다. 작년에 DNN 모듈에서 종속성 주입을 구현했을 때 개발자가 자신의 기술을 아주 쉽게 이전할 수 있도록 비슷한 작업을 수행했습니다.

모든 시작 코드를 처리하는 App.cs 또는 App.xaml.cs 바로 옆에 있는 Startup.cs를 만들어야 한다고 생각합니다.

신규 사용자는 이 모든 부트스트랩 작업을 이해하고 싶어하지 않을 것입니다. 제 생각에는 MAUI가 AppDelegate, MainActivity 등 1 startup/app.xaml 주변의 모든 상용구를 완화하여 모두를 지배할 것이기 때문에 이것이 특히 당신이 원하는 마지막 것입니다.

@aritchie 동의

가능한 한 많은 사람들을 활성화하고 싶지만 신규 사용자의 경우 이 대부분이 숨겨져 있을 수 있습니다.
그러나 일단 그들이 편안해지면 물건을 확장하기 시작할 수 있습니다.

여기에 사용자가 모든 것을 사지 않고도 이점을 얻을 수 있는 시나리오가 있다고 생각합니다.

예를 들어 Shell을 사용하면 다음과 같은 RegisterRoute 구문을 도입할 수 있습니다.

Shell.RegisterRoute<TBindingContext, TPage>(String routeName);
아니면 그냥
Shell.RegisterRoute<TType>();

후드 아래에서 이 모든 것을 사용하여 유형을 만듭니다. 그런 다음 사용자가 등에 주입될 HttpContext를 원하는 경우.

이 제안의 다른 부분은 재미있는 시나리오를 가능하게 하는 IServiceProvider를 통해 모든 DataTemplate을 시도하고 생성하는 것입니다.

나는 James의 샘플을 기반으로 Shell과 함께 몇 가지 변형을 가지고 놀고있었습니다.

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

@charlesroddie

사람들이 리플렉션/컨벤션/주석 기반 방식으로 뷰 모델을 얻으려면 MAUI가 정말 명시적인 지원을 제공해야 합니까?

현재로서는 성능상의 이유로 반영을 통해 아무것도 제공하지 않을 계획입니다. 성능 저하 없이 등록을 단순화할 수 있는 일부 영역이 있을 수 있지만 여전히 이러한 영역을 탐색해야 합니다.

또한 등록 구문으로 원래 주석을 업데이트했습니다.

@PureWeen

Prism과 같은 것이 모델에 플러그인할 수 있도록 IServiceCollection에서 일종의 경로 확장을 갖는 것이 좋습니다. 저는 XF를 수년간 사용해 왔으며 Shell은 사용하지 않습니다.

즉. services.UseRoute(선택적 이름)

다른 참고 사항으로 Shiny는 다른 아이디어가 필요한 경우 Microsoft DI 메커니즘과 관련하여 광범위하게 사용됩니다. 나는 호스트 빌더 모델(현재 형태의)을 거부하게 되었는데, 그 이유는 링커와의 끔찍한 싸움으로 이어지는 많은 것들이 있었기 때문입니다. 언젠가는 전화로 이러한 경험을 공유하고 싶습니다.

아마도 소스 생성기를 사용하여 성능 문제를 완화할 수 있습니까? 그런 다음 사용자 정의 속성을 계속 사용할 수 있지만 생성된 소스 파일에서 모든(기본값) 등록을 수행합니다.

@aritchie는 좋은 것 같습니다!

일단 우리가 재미있는 빌드의 반대편에 있으면 채팅합시다!

@rogihee

아마도 소스 생성기

응!! 우리는 Maui 이전에 현재 렌더러 등록을 재구성하기를 원하며 해당 작업을 위한 소스 생성기를 찾고 있습니다. 우리가 그 길을 간다면 우리는 이것을 위해 확실히 활용할 수 있습니다

Xamarin Forms에 DI가 있으면 좋겠지만 DI 범위에 대한 내용은 읽지 않습니다. DI 범위를 사용하는 것은 구성 요소의 수명을 관리하는 좋은 방법입니다. EF 코어의 데이터베이스 컨텍스트로 작업할 때 특히 유용합니다.

범위를 만들고 이 범위에 대한 명령 처리기 개체를 요청하는 DI 인식 ICommand 구현이 있으면 좋을 것입니다.

WPF 응용 프로그램에서 종속성 주입을 사용하는 것도 어렵습니다. 따라서 WPF 팀과 팀을 이루어 비슷한 방식으로 WPF에서 DI를 사용할 수 있습니다.

유일한 질문은 기본 구현을 위해 이미 구현된 컨테이너를 사용해야 하는지 아니면 성능 면에서 조금 더 모바일 지향적인 자체 컨테이너를 롤링해야 하는지 여부입니다.

마우이용 컨테이너를 처음부터 구현한다고 말하고 싶습니다. 여기 에서 볼 수 있듯이 DependecyService 구현된 Xamarin.Forms 가 더 빠릅니다. (알아요... 그 글은 좀 오래된 글이지만 가치관이 많이 바뀌는 것 같지는 않습니다.)
또한 성능 면에서 자체 DI 컨테이너를 만드는 것이 훨씬 좋습니다. 하지만 제 걱정은 .NET 5가 없는 세상입니다. .NET 5와 소스 코드 생성기를 사용하면 이 문제에 대한 또 다른 솔루션을 얻을 수 있습니다.
그리고 모바일 의 경우 무거운 DI가 필요한 경우 뭔가 잘못하고 있는 것입니다.

저는 MAUI 애플리케이션이 일반 호스트(Microsoft.Extensions.Hosting)를 지원하도록 제안하기 위해 이 리포지토리에 왔습니다. UI 애플리케이션에 DI가 있는 것이 매우 자연스럽기 때문에 기본적으로 선호됩니다(일부 사람들은 보호하기를 원할 수도 있음). 이는 사람들이 asp.net 코어에 대한 종속성 주입에 익숙하다면 MAUI에서도 작동하는 것보다 덜 이해할 필요가 있음을 의미합니다. 초보자의 경우 구성을 매우 최소한으로 유지하는 것이 좋습니다.

첫 번째가 되는 대신 이 문제를 찾았고 좋은 토론이라고 생각합니다!

일부 서비스와 작은 UI(상태, 구성 등)를 제공하는 애플리케이션을 갖는 것은 여전히 ​​일반적인 일입니다. 일부 서비스를 제공하는 작은 애플리케이션을 빌드할 때마다 UI로 이를 확장해야 할 필요성을 계속 느낍니다.

https://github.com/dapplo/Dapplo.Microsoft.Extensions.Hosting 프로젝트에서 볼 수 있듯이 Windows Forms 및 WPF 응용 프로그램을 일반 호스트에서 실행할 수 있도록 이미 빌드했습니다.
나는 이것을 Greenshot에 사용하기를 바랐지만, 현재 나는 아직 그것에 대해 아무 것도 발표하지 않았습니다.
샘플에는 ReactiveUI, MahApps 및 Caliburn.Micro를 사용하는 WPF 프로젝트가 있습니다.

DI에 수동으로 보기를 등록하게 하지 마십시오. blazor에서 최고를 얻으십시오. 훌륭합니다! blazor에서는 매개변수를 쉽게 전달하거나 구성 요소에 서비스를 주입할 수 있습니다. 자체 구성 요소를 등록할 필요가 없습니다. 서비스만 등록하면 됩니다. MVVM은 페이지에 적합하지만 이러한 자체 호스팅 구성 요소 보기를 생성하는 것이 더 생산적이라고 느낀 적은 없습니다. 나는 기본적으로 제공되지 않는 것들 때문에 새로운 Xamarin, WPF, UWP 프로젝트를 시작하는 것을 싫어합니다. 미래의 모든 GUI 프레임워크에 대한 진정한 청사진인 Blazor를 다시 한 번 살펴보십시오.

왜 누군가가 다음과 같은 두 가지 연속적인 진술을 작성하는지 이해할 수 없습니다.

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

뷰 코드 뒤에 서비스를 주입하는 것이 잘못된 것은 무엇입니까? 99.99%의 시간 동안 원하는 것입니다.

또한 저는 생성자 주입 대신 blazor의 속성 주입이 더 쉽기 때문에 매우 좋아합니다.

실제로 Xamarin.Forms https://github.com/hostly-org/hostly 에 대해 이 작업을 수행하는 라이브러리를 방금 출시했습니다. 기본 진입점에서 쉽게 설정할 수 있는 IHost의 사용자 지정 구현을 사용합니다. 예를 들어 MainActivity 다음을 대체합니다.

LoadApplication(new App());`

와 함께:

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

또한 탐색에 미들웨어를 등록하기 위한 지원과 같은 몇 가지 추가 기능이 내장되어 있습니다.

저는 코드를 MAUI 및 비 MAUI 프로젝트와 공유할 수 있도록 System.Maui 네임스페이스 외부에 있는 DI 시스템을 사용하는 것을 찬성합니다.

내가 덜 확신하는 부분은 Microsoft.Extensions.DependencyInjection 또는 이를 기반으로 하는 것을 DI 시스템으로 사용하는 것입니다. 나는 이것에 대해 전문가인 척하지 않을 것입니다. 나는 확실히 여러 현대 DI 시스템을 직접 사용해 본 적이 없습니다. 그러나 다른 사람들은 "Dependency Injection. Principles, Practices and Patterns”(Steven van Deursen과 Mark Seemann 저). 그들은 Autofac, Simple Injector 및 Microsoft.Extensions.DependencyInjection을 살펴보는 데 두 번째 판의 섹션을 할애하고, 자신의 의견/결론뿐만 아니라 장단점을 제공합니다. MAUI 세계에서 Microsoft.Extensions.DependencyInjection(주로 다른 Microsoft 시나리오에서 사용됨)을 사용하면 몇 가지 이점을 볼 수 있지만, 여기에서 여러 DI 시스템 경험이 있는 사람이 작성자의 결론과 어느 정도에 대해 논평할 수 있는지 궁금합니다. 모바일 및 데스크탑 사용의 MAUI 세계와 관련이 있습니까?