Make Dependency Injection with Avalonia possible?

[duongphuhiep]

Hello,

Avalonia doesn't support Dependency Injection. You can use whatever DI Container in your Avalonia application but you are on your own. There is simply no integration point telling Avalonia to use your DI Container when resolve a View.

I looked at the code generated by Avalonia from the following Xaml and something surprise me..

<Window x:Class="AvaloniaDemoDI.MainWindow" xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:v="using:AvaloniaDemoDI"
        Title="AvaloniaDemoDI" d:DesignHeight="450"
        d:DesignWidth="800" mc:Ignorable="d">
    <v:MyUserControl />
</Window>

1. Look at the Line 43, why does Avalonia do new MyUserControl() while it could use the ServiceProvider P_0 to resolve this object? Avalonia can fallback to new MyUserControl() in case the ServiceProvider P_0 are unable to resolve object.

2. Is there a way to tell Avalonia to use our IServiceProvider to resolve object? which means Avalonia should change the line 63 and use our ServiceProvider instead of creating a new one..

Dependency Injection is possible with Avalonia, only if it can answer these 2 problems.

[rabbitism]

Most of the time visual elements should not be reused because they cannot be attached to visual tree again and again. Why do you want to do this?

[duongphuhiep]

Hello, there is nothing to do with reuse visual elements.

The point is that Avalonia should not create (or resolve) the object MyUserControl. It is the responsibility of the IServiceProvider

If Avalonia let the IServiceProvider does the job, then there is a lot of benefit. The most obivious is that we can inject things to MyUserControl(). A typical use case: MyUserControl depends on MyUserControlViewModel which depend on some kind of IMyRepository.

class MyUserControl(MyUserControlViewModel viewModel);
class MyUserControlViewModel(IMyRepository repositoy);
interface IMyRepository;
class PostgresRepository: IMyRepository;

Avalonia doesn't know how to create this kind of MyUserControl because it doesn't have a default constructor.. But IServiceProvider knows.. IServiceProvider knows to do new MyUserControl(new MyUserControlViewModel(new MyPostgresRepository)).

• Don't worry about perf, IServiceProvider (precisely, the DI framework behind the IServiceProvider) has many trick to create object fast! (Lazy, Task, Func, Property injection...). It is the expert in object creation..

• About reusing visual elements: If Avalonia gives the responsibility of creating object back to the expert (IServiceProvider), then it won't know if the IServiceProvider would reuse or create a new MyUserControl instance. Only developer (me) who configured the IServiceProvider would decide which Element I want to reuse, which one would be re-created each time,

• If Avalonia absolutely wants that IServiceProvider should always create a new MyUserControl then it shouldn't be hard to add a protection.

• if the IServiceProvider is used then it would be also possible to automatically set (or Resolve) the DataContex of MyUserControl

[maxkatz6]

Hi.
Dependency injection into visual controls is not planned.

[maxkatz6]

In short, because DataContext is preferred way to supply model or business information to your controls. Because of how XAML inherently works.

XAML assumes, that all the state of control can be changed via its properties, including DataContext.
And that's actively used in scenarios like virtualization. Where single Control can be used to represent thousands of date context items, one at a time, being reused when list is scrolled.

Of course, even with virtualization scenario in mind, it is still acceptable to inject unchanging services via constructor, as an addition to the changing DataContext. And you can achieve that via IDataTemplate/IViewLocator or custom MarkupExtension as I mentioned below.

[maxkatz6]

Also, Property Dependency Injection is still a thing. And it works better with XAML in general.

[duongphuhiep]

I agree that, Property Dependency Injection is still a thing, Many DI Container (Stashbox, SimpleInjector, Dryloc..) support Property Injection. I wanted to use Stashbox to automatically inject my ViewModel to the DataContext property of the View. But because Avalonia won't use my DI Container to create the View so the idea is simply impossible.

ASP.NET, Blazor.. heavily depends on DI Container to manage object creation and their lifetime. I wonder why not considering it for Avalonia... Anyway in my case the workaround below with "Markup extension" is good enough, thanks again

[maxkatz6]

Is there a way to tell Avalonia to use our IServiceProvider to resolve object?

This part is actually possible.
You can write your own MarkupExtension which accepts control Type as a parameter and returns resolved object from the ProvideValue.

[maxkatz6]

    <StackPanel>
        <local:ResolveControl ControlType="local:DependencyUserControl" />
    </StackPanel>

public partial class DependencyUserControl : UserControl
{
    public DependencyUserControl(DependencyService service)
    {
        InitializeComponent();
    }
}

public class ResolveControlExtension
{
    public Type ControlType { get; set; }

    // note, this IServiceProvider parameter IS NOT related to your configured service provider, and only used for XAML related services
    public Control ProvideValue(IServiceProvider _) 
    {
        if (!typeof(Control).IsAssignableFrom(ControlType))
            throw new InvalidOperationException($"The provided type {ControlType} is not a control");

        // TODO, you can replace this logic with your own DI/IoC solution.
        if (ControlType == typeof(DependencyUserControl))
        {
            return new DependencyUserControl(new DependencyService());
        }

        throw new InvalidOperationException($"The provided type {ControlType} is not registered");
    }
}

[maxkatz6]

SimpleAvaloniaDIExtension.zip

[maxkatz6]

Note, you can extend ResolveControlExtension to any type that can be used in XAML.
Just replace Control ProvideValue() with object ProvideValue() or other more specific type.

[duongphuhiep]

Thanks @maxkatz6 the ResolveControlExtension is very closed to what I'm looking for.

However, controls which are resolved by the ResolveControlExtension is not "normal" in the XAML.
You cannot easily set the properties of the control as other "normal" controls. For eg:

<local:ResolveControl ControlType="local:DependencyUserControl" background="yellow" somePropertyOfTheUserControl="toto" />

Use Markup extension this way cannot completely make up for the lack of DI in Avalonia, but it is a nice workaround though!