Is there any reason why I should not register all my dependencies at Shiny Startup?

[ghost]

Hi.

I've written a very simple MVVM framework for myself using Microsoft.Extensions.DependencyInjection. It's stupidly primative , and it just exists so that I don't need to manually new up a BindingContext for each page and constructor inject my services manually.

I register these services in my App.xaml.cs, in the same way that you would if the app was using Prism - for example.

The problem is, I want some of the Shiny services available to me as well. I'm writing a lot of unit tests, so I don't really want to call ShinyHost.Resolve in a ViewModel/Service constructor.

So I've used the CreateServiceProvider override of ShinyStartup, and returned my ServiceCollection.BuildServiceProvider there.

The problem I now have, is that the ServiceCollection (https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection.serviceprovider?view=dotnet-plat-ext-6.0) doesn't have any methods to merge in another service collection. So I need to migrate my IServiceCollection setup from App.xaml.cs and use the same IServiceCollection instance passed to the CreateServiceProvider override. That way, the Shiny services and my services are all happy together in the same container.

With that explained, my question is, is there an issue with doing that? Or is there something missing in this process that I just don't get?

Could I get away with ditching my ServiceProvider and just Resolve from the ShinyHost directly?

[aritchie]

There is nothing wrong with what you are doing as long as you don't have a massive dependency chain that takes too long to validate that it cuts into the background startup.

You can also do a services.AddSingleton(_ => ShinyHost.Resolve()) to register with your secondary container.

Lastly, you can look at Shiny.Framework which uses DryIoc (a mutable container).

The following samples may help:
https://github.com/shinyorg/samples/tree/main/Integration-Best-Prism-RXUI
https://github.com/shinyorg/samples/tree/main/Integration-Prism

With these samples, you'll notice a distinct separation between viewmodel registration (which is still DI) and services/shiny yet it is all in one container.

[ghost]

Perfect. That's great, thanks Allan.

This app is small enough to get away with just using the shiny startup and resolving directly from it, so I'll go down that route here.

For future, larger apps, I'll look at using a mutable container.

Cheers for the reply, have a good day!