Another .NET Blog

Here, I won't explain what are Caliburn and PostSharp. Their respective documentations, examples and samples already do that very well. But I will show you how to create an aspect which will be applied by PostSharp on the view models of a WPF assembly.

And as a result, on runtime, each time a public property will be changed, the event PropertyChanged of the interface INotifyPropertyChanged will be fired, and the WPF view will be able to refresh its state.

If you already know PostSharp, or have been on their website, you have certainly noticed that they already propose an aspect which intends to implement the interface INotifyPropertyChanged, and to call PropertyChanged when the value of a property is changed.

And if you already know Caliburn, you know that the classes you must inherit from to implement your view models inherit themselves from an abstract class named PropertyChangedBase, which implements INotifyPropertyChanged, and which proposes a function named NotifyOfPropertyChange, to which you give as a parameter the name of the modified property.

The aspect I'm going to show you will allow us to mix these 2 methods.

Dans cet article, je ne vais pas vous expliquer ce que sont Caliburn et PostSharp, leurs documentations et exemples respectifs le font déjà très bien, mais je vais expliquer comment créer un aspect que Postsharp va appliquer à des classes que nous définirons, et qui aura pour résultat d'implémenter l'interface INotifyPropertyChanged dans ces classes, et d'appeler automatiquement l'évènement PropertyChanged lorsque la valeur des propriétés publiques de ces classes va être modifiée.

Si vous connaissez déjà Postsharp, ou avez été regardé sur leur site, vous aurez sûrement remarqué qu'il existe déjà un aspect qui permet d'implémenter l'interface INotifyPropertyChanged, et d'appeler PropertyChanged à chaque changement de valeur de la propriété.

De même, si vous connaissez Caliburn, vous aurez également remarqué que les classes dont vous devez dériver pour implémenter vos ViewModels dérivent elles-même d'une classe abstraite nommée PropertyChangedBase, qui implémente INotifyPropertyChanged, et qui propose une fonction nommée NotifyOfPropertyChange, à laquelle vous passez comme paramètre le nom de la propriété qui a été modifiée.

L'aspect que je vais vous montrer va nous permettre de mixer ces 2 approches.

Le problème est classique: vous créez un thread pour réaliser une opération, et vous voulez que ce thread modifie un composant graphique (comme une ProgressBar par exemple). La solution, que vous devez sûrement connaître, consiste à exécuter l'action en question sur le même thread que celui de l'UI, c'est à dire, en WPF, utiliser la fonction BeginInvoke de la propriété Dispatcher de votre contrôle. Si vous avez un grand nombre de modifications de votre interface utilisateur qui sont effectués depuis une ou plusieurs tâches, plutôt que d'appeler BeginInvoke de multiples fois, il existe une solution toute simple, qui consiste à créer et lancer vos tâches en utilisant une TaskFactory à laquelle vous aurez donné comme TaskScheduler celui chargé de gérer l'UI.

Pour cela, c'est très simple:

public partial class MyUserControl : UserControl
{
    private TaskFactory _ui;

    public MyUserControl()
    {
        InitializeComponent();

        _ui = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext()); 
        _ui.StartNew(() => { Width = 100; } );
    }
}

Et donc toutes les tâches que vous créerez depuis cette TaskFactory seront "schedulées" (je ne sais pas trop comment traduire ça au mieux) sur le thread de l'UI, et donc vous dispensera d'utiliser Dispatcher.BeginInvoke à tout va.

A noter que le code suivant fonctionne tout aussi bien:

public partial class MyUserControl : UserControl
{
    private TaskScheduler _ts;

    public MyUserControl()
    {
        InitializeComponent();

        _ts = TaskScheduler.FromCurrentSynchronizationContext();
        Task.Factory.StartNew(() => { Width = 100; }, _ts);
    }
}