Dependency Injection in an IValueConverter

[symbiogenesis]

In the old Xamarin.Forms, you could do DI using static functions and put them anywhere, including in converters.

I much prefer the approach that leverages Microsoft.Extensions.DependencyInjection, but what is the best pattern for converters now?

Here's what I know:

• If you instantiate the converters in code, rather than XAML, then you could put parameters into them from wherever, although it could get a little complicated if you need multiple services or already have a parameter being passed in. But to me that defeats the entire point of converters, which is a way to write clean XAML.
• If you use a library like Prism then you can wrap converters in a container
• As with all programming problems, you can solve this problem with yet another layer of indirection. Like wrapping the objects you are using via a factory or whatever. But since converters are themselves a layer of indirection, then you could just do the converting inside that factory and ditch the converter. Which is a shame since converters are nice and clean.
• If you kept a static reference to your service or to IServiceProvider then you could use that, which would be a horrible anti-pattern.

Prism.Maui is only in beta.

Since I like XAML, do not use Prism, want to keep using converters, and want to avoid anti-patterns... it makes me wonder what the right approach is.

The answer that seems most obvious given the nature of converters is that they are meant to be simple immutable stateless functions, and I should only use them when I need to do trivial conversions that don't rely on services.

And thus, building some kind of wrapper or factory is the right approach when services are required. Am I missing anything?

[sigged]

This is sorely needed!

[FM1973]

It is some sort of anti pattern, but I´m using a static service helper class.

public static class ServiceHelper
    {
        public static TService GetService<TService>()
        {
            var service = Current.GetService<TService>();
            return service;
        }

        public static IServiceProvider Current =>
#if WINDOWS
            MauiWinUIApplication.Current.Services;
#elif ANDROID
            MauiApplication.Current.Services;
#elif IOS || MACCATALYST
            MauiUIApplicationDelegate.Current.Services;
#else
            null;
#endif 
}

And then use it like this:

var serviceX = ServiceHelper.GetService<IServiceX>();

But I would prefer some sort of constructor or property injection.

[symbiogenesis]

Yea, I can see why they removed this approach. Converters are the one place that the old pattern seems essential, but it probably should be avoided there too.

I think I ended up avoiding using this approach, by creating extra pages and controls, and passing data into those to be processed within the other ViewModels.

It seems to me that if what you want to do is inject a service into an IValueConverter, then in reality you probably ought to do some refactoring. Keep IValueConverters for simple conversions.

If whatever it is you are doing is a complicated enough conversion that you feel a need to pull in other services that you felt a need to inject, then inject them into additional ViewModels.

Alternatively, extract the needed functionality out of the injected service and move it into a simple static helper function. I have some code like that for dealing with MapSpan values, and call them from converters. But it is static, so it is fine, and a good use for a converter.

[symbiogenesis]

For instance, I have a complicated view that allows editing a parent record and a bunch of child records simultaneously. So inside my ViewModel, I have a line that looks like this

public ObservableRangeCollection<RecordTypeFieldViewModel> RecordTypeFields { get; } = new();
And I can instantiate those ViewModels however I like. One way that you can instantiate them is by injecting IServiceProvider into the parent view model. Then you can use the IServiceProvider to resolve as many transient child view models as you like. Or you can just new them up directly. Or some combination.

Injecting IServiceProvider for resolving services in a delayed fashion, more like Xamarin.Forms allows, is a perfect pattern that still follows all the best practices.

[sigged]

It seems to me that if what you want to do is inject a service into an IValueConverter, then in reality you probably ought to do some refactoring. Keep IValueConverters for simple conversions.

Valid point, but I my case I wanted to use a custom IUrlBuilder to create a URI for use in an image, while the ViewModel was only capable of holding an Id to construct that URI with.
Building the URI in the ViewModel in our case would have meant a big refactoring which was avoided by moving the simple Id to URI conversion into... a converter :)

So I would argue that not every injected dependency means it's doing something complex.

[FM1973]

Agreed. But you really have to be careful.
I don't like this approach either, but there are a few situations where it is very handy.

[symbiogenesis]

Another interesting option

https://stackoverflow.com/questions/58181277/xamarin-forms-xaml-converter-bindable-property

[symbiogenesis]

Recommend not using a static IServiceProvider. If you run into this issue, I think it is a potential sign that you should consider a bit of refactoring.

Here are a number of better options, in my opinion:

• Injecting the service into the ViewModel, and then exposing another property that provides the processed data.
• If there is a reason you wanted to delay injecting the service directly into the ViewModel, then inject IServiceProvider into the constructor of the ViewModel, and do the same thing as above.
• Make more pages and custom components as needed, and do the transformations inside of those. Having nested custom components inside of a page that have their own ViewModel is a perfectly good pattern. But, even from an MVVM perspective, custom components don't actually need to have ViewModels, if they are just handling something presentation-related.
• Expose the instance of the service to the converter as a ConverterParameter
• Make the converter a BindableObject and then bind the instance of the service to the converter by adding a public BindableProperty to the converter. This option is very much like creating a custom control, since the converter becomes bindable like a control.
• Make the URI-building functionality you have static, and then reference the functions as static functions. i.e. FooHelper.DoSomething(someParameter) ...and you can do this without moving functionality to another class. The class itself doesn't need to be static, if all you want is to call a static function from it. Just make sure to pass all data it needs as a parameters.

[sigged]

Good workarounds to avoid the static IServiceProvider anti-pattern.
I would like to add on more solution to the list, which enables injecting directly into the IValueConverter.

• Add the converter to the Resources using C# instead of XAML

public App(IDependency injectme)
{
     var converter = new MyConverter(injectme);
     Application.Current.Resources.Add(nameof(MyConverter), converter);
}

This means we could also register the converter itself and let the container construct it before adding it to the resources dictionary.

builder.Services.AddSingleton<MyConverter>();

public App(MyConverter converter)
{
     Application.Current.Resources.Add(nameof(MyConverter), converter);
}

Or move on from here with a Converter factory, etc, etc. All good, as long as we can avoid this:

<ResourceDictionary>
   <converters:MyConverter x:Key="MyConverter" />
</ResourceDictionary>

[symbiogenesis]

With transient services you would need to be doing this a lot, and you would need to be careful to avoid converter objects cluttering up in your memory, and it seems to kind of defeat some of the point.

In my view, what is nice about converters is that they are a simple way to transform data bindings in an MVVM context, when you are using XAML. But having to start worrying about the Resource dictionary or XAML objects from within the code is a violation of MVVM principles, and converters are XAML objects for all intents and purposes.

And ideally to follow the principle of encapsulation, and efficient loading, the converter should only be defined where it needs to be. Not always at the app-level.

The approach in the link seems more MVVM-friendly, in my opinion. You would be able to handle services that are either transient or singleton, you could define the converter in any scope you like, and you can do everything with binding and thus update everything as needed, while not needing to be concerned at all with presentation-layer issues inside the ViewModel.