The MVVM Pattern revisited with the MVVM Community Toolkit 8.0

Sometime ago, I've written this article introducing the MVVM Community Toolkit and developing a CRUD application to show how to use the MVVM pattern with the Community toolkit.

The time has passed and version 8.0 of the MVVM Community toolkit has been released and, with it, a rewrite using incremental generators. This may seem a minor update, but it's a huge move, as the MVVM pattern is full of boilerplate: implementing the INotifyPropertyChanged interface for the viewmodels, binding commands that implement the ICommand interface, using the RelayCommand class and implementing observable properties that raise the PropertyChanged event when changed. All that make the code cumbersome and repetitive, but that's what we had to do to implement the MVVM pattern in our apps. Until now.

With the use of source generators, the toolkit removes a lot of the boilerplate and makes the code easier to create and read. In this article, we'll take the project that we developed in the previous article and will change it to use the new toolkit.

You can clone the code in https://github.com/bsonnino/MvvmApp and open the CustomerApp - Mvvm app in Visual Studio 2022. As the original project is targeted to .NET 5.0, we'll upgrade it to .NET 6.0. This is an easy task: just open CustomerApp.csproj and change the TargetFramework to .net6.0-windows:

<PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net6.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

Do the same with CustomerApp.Tests.csproj. There is no need to do it on the CustomerLib project, as it's a Net Standard project.

The next step is to update the NuGet packages. The package Microsoft.Extensions.DependencyInjection must be upgraded to version 6.0.0. If you try to upgrade the Microsoft.Toolkit.Mvvm package, you'll see that there is no upgrade to version 8.0. That's because the package name has changed and you must uninstall this one and install the CommunityToolkit.Mvvm package.

Now, the project is ready to build and, when you do that, you'll see that it doesn't work . This is because the namespaces have changed and we need to update the using clauses in MainViewModel.cs. We have to remove the old using clauses and replace with the new ones:

using Microsoft.Toolkit.Mvvm.ComponentModel;
using Microsoft.Toolkit.Mvvm.Input;

using CommunityToolkit.Mvvm.ComponentModel;
using CommunityToolkit.Mvvm.Input;

Once you do that and recompile the project, you'll see that it compiles fine and runs in the same way the original project did. Not bad for a project upgraded from .NET 5 to .NET 6, with a new version of the MVVM framework.

But did I say that with the new toolkit you can remove the boilerplate? We can start doing that now. The first thing is to remove the properties and their getters and setters. We decorate the _selectedCustomer field with the [ObservableProperty] attribute:

[ObservableProperty]
private Customer _selectedCustomer;

When you do that, you'll see that the class name has a red underline:

That's because when we add the attribute, the toolkit generates a partial class, and we need to add the partial keyword to the class:

public partial class MainViewModel : ObservableObject

When we add that, SelectedCustomer is underlined:

That's because we have declared the property in our code and the toolkit has also declared the same property in the generated code. We can now remove the property declaration from our code:

public Customer SelectedCustomer
{
    get => _selectedCustomer;
    set
    {
        SetProperty(ref _selectedCustomer, value);
        RemoveCommand.NotifyCanExecuteChanged();
    }
}

As you can see from the code we are removing, the setter notifies the RemoveCommand. To have the same effect, we add the NotifyCanExecuteChangedFor attribute to the field:

[ObservableProperty]
[NotifyCanExecuteChangedFor(nameof(RemoveCommand))]
private Customer _selectedCustomer;

If you compile the code, you will see that it runs the same way it did before, and we are still using the property name (SelectedCommand) in the commands, even if it's not explicitly defined in the code. That's because the toolkit is generating the property in its partial part of the class.

The next steps are to remove the boilerplate from the commands in the code. For that, we must remove all declarations and leave only the command methods, changing their name to the command name (without Command at the end) and adding the [RelayCommand] attribute for the method. For the Add command, we have to change this code:

public IRelayCommand AddCommand { get; }

private void DoAdd()
{
    var customer = new Customer();
    _customerRepository.Add(customer);
    SelectedCustomer = customer;
    OnPropertyChanged("Customers");
}

To this code:

[RelayCommand]
private void Add()
{
    var customer = new Customer();
    _customerRepository.Add(customer);
    SelectedCustomer = customer;
    OnPropertyChanged("Customers");
}

We also have to remove the initialization code:

AddCommand = new RelayCommand(DoAdd);
RemoveCommand = new RelayCommand(DoRemove, () => SelectedCustomer != null);
SaveCommand = new RelayCommand(DoSave);
SearchCommand = new RelayCommand<string>(DoSearch);

If you notice the removed code, you'll see that the RemoveCommand has a CanExecute method. To solve that, we have to have to add a parameter to RelayCommand:

[RelayCommand(CanExecute = "HasSelectedCustomer")]
private void Remove()
{

The parameter points to HasSelectedCustomer, a method that should be defined in the code:

private bool HasSelectedCustomer() => SelectedCustomer != null;

With that, we have completed our code and now the project runs in the same way it did before. The code is simpler and with no boilerplate:

public partial class MainViewModel : ObservableObject
{
    private readonly ICustomerRepository _customerRepository;

    [ObservableProperty]
    [NotifyCanExecuteChangedFor(nameof(RemoveCommand))]
    private Customer _selectedCustomer;

    public MainViewModel(ICustomerRepository customerRepository)
    {
        _customerRepository = customerRepository ??
                              throw new ArgumentNullException("customerRepository");
    }

    public IEnumerable<Customer> Customers => _customerRepository.Customers;

    [RelayCommand]
    private void Add()
    {
        var customer = new Customer();
        _customerRepository.Add(customer);
        SelectedCustomer = customer;
        OnPropertyChanged("Customers");
    }

    [RelayCommand(CanExecute = "HasSelectedCustomer")]
    private void Remove()
    {
        if (SelectedCustomer != null)
        {
            _customerRepository.Remove(SelectedCustomer);
            SelectedCustomer = null;
            OnPropertyChanged("Customers");
        }
    }

    private bool HasSelectedCustomer() => SelectedCustomer != null;

    [RelayCommand]
    private void Save()
    {
        _customerRepository.Commit();
    }

    [RelayCommand]
    private void Search(string textToSearch)
    {
        var coll = CollectionViewSource.GetDefaultView(Customers);
        if (!string.IsNullOrWhiteSpace(textToSearch))
            coll.Filter = c => ((Customer)c).Country.ToLower().Contains(textToSearch.ToLower());
        else
            coll.Filter = null;
    }
}

As you can see, this new version brought a huge improvement. We can use the MVVM pattern with no issues, there is no extra code related to the pattern (except for the attributes) and the code is easier to read and follow. And all tests still run, with no change at all.

The full source code for this article is at