Bon, pour ma part j’ai trouvé que ça s’était plutôt bien passé considérant que je ne suis pas un speaker – au mieux un sale programmeur – même si j’imaginais une présentation un peu plus courte. J’ai parlé pendant 45 min, je crois, puis j’ai ouvert VS pour la “démo interactive” qui s’est un peu éternisée.

Je tiens encore à remercier FastConnect pour la salle, l’organisation, le buffet, etc.

En ce qui concerne le code des exemples, j’essaierai d’éditer ce post ultérieurement.

Edit Quelques liens en rapport :

• INotifyPropertyChanged avec PostSharp
• INotifyPropertyChanged avec Mono.Cecil

Edit Le compte rendu de la soirée est maintenant dispo sur le site ALT.NET Fr. Merci Jb.

N’hésitez pas à me faire part de vos critiques positives, puisque les autres, constructives ou pas, elles vexent. OK ?

Je voulais vous informer, ou plus probablement vous rappeler, que j’allais commettre une présentation sur l’AOP, le 17 juin, à l’occasion de la 14ème rencontre ALT.NET Parisienne. Vous trouverez les détails pratiques sur notre joli site. Merci à FastConnect qui sponsorise l’évènement.

Il va sans dire que je serais plus à l’aise s’il n’y avait que 3 personnes qui jugeaient bon de se déplacer. Pourtant, je vais m’asseoir sur cette considération et vous inviter à venir nombreux. Plusieurs fois au cours des rencontres précédentes nous avons abordé la question de la programmation orientée aspect lors des discussions libres, et il semblerait donc que le sujet rende curieux, à défaut de préoccuper. Peut-être mérite-t-il que nous lui fassions plus de place le temps d’une soirée. Je ne sais pas encore exactement quel sera l’agenda, mais l’idée est de présenter l’AOP en tant que concept, de le confronter gentiment aux paradigmes traditionnels, avant de passer plus concrètement à l’étude des différentes techniques et outils qui existent en .NET.

D’aucuns pourraient penser que le sujet n’est pas spécialement ALT.NET.

Ce à quoi je répondrais :

Certes, certes…

Enfin. Si on compte uniquement sur Microsoft pour profiter de l’AOP on risque assez rapidement de se sentir à l’étroit. Il est possible de faire de l’AOP sans sortir de la BCL, oui, et il est possible de faire de l’AOP un peu plus facilement en débordant sur EntLib. Cependant, les solutions les plus matures et les plus riches pour faire de l’AOP en .NET ne sont pas forcément estampillées Microsoft, ce qui risque de conduire l’utilisateur averti vers des frameworks plus spécialisés, open-source ou pas. Je veux parler de Castle.DynamicProxy, PostSharp, Linfu, Mono.Cecil, Spring.NET, etc.

Moi, je trouve que ça sent ALT.NET.

Bref, j’espère que cette rencontre verra naitre un débat et que nous pourrons collecter quelques retours d’expériences, comparer nos approches, bailler, etc. Encore une fois, toutes les infos sont disponibles sur le site altnetfr, à cette adresse.

Pensez à vous inscrire, et n’hésitez pas à faire passer l’info.

En revanche, aucune autre méthode à ma connaissance ne permet d’obtenir un tissage aussi fin. Par fin, j’entends spécifique, propre, non pollué par le code que génèrent les outils d’AOP classiques pour supporter les mécanismes d’interception. Donc les performances seront à la clé puisqu’une fois l’assembly retravaillé avec Cecil, il ne sera plus possible de faire la différence entre son code IL et celui qui aurait été généré si nous avions implémenté INotifyPropertyChanged à la main. Le développement aura juste été un peu plus cher…

Même si la plupart du temps vous préfèrerez sans doute bénéficier de l’abstraction offerte par les outils d’AOP classiques, vous trouverez peut-être excitant de jouer avec Cecil pour déveloper des aspects bas niveau en mettant les mains dans le camboui. (Vous pouvez aussi trouver ça naze au point d’en bailler, hein.)

Bref, ce post va plus ressembler à un article sur Cecil qu’à un article sur INotifyPropertyChanged. Il y aura probablement deux parties, mais ce n’est pas une promesse :

• Part 1 : première version d’un transformer utilisant Cecil pour implémenter INotifyPropertyChanged (cet article)
• Part 2 : version améliorée du transformer lançant l’évènement de notification uniquement lorsque la valeur affectée à la propriété est différente

Eventuellement, je fournirai quelques pistes pour lancer automatiquement ce genre de transformations en post-build dans la seconde partie, si seconde partie il y a.

Mais commençons par le commencement, en prenant pour victime la Person des articles précédents. Le but est de pouvoir écrire :

	[NotifyPropertyChanged]
	public class Person
	{
		private string name;

		public string Name
		{
			get { return this.name; }
			set { this.name = value; }
		}
	}

et d’obtenir au final une classe Person implémentant INotifyPropertyChanged et capable donc de notifier par l’événement PropertyChanged les changements de ses propriétés.

Cecil permet de charger un assembly, de l’inspecter et de le modifier éventuellement avant de le sauvegarder, de le copier, etc. L’idée consiste donc à :

1. Compiler le code ci-dessus normalement, afin d’obtenir un assembly
2. Lancer un transformer, qui utilise Cecil afin de charger cet assembly
3. Modifier l’assembly, toujours avec Cecil, pour y injecter l’implémentation d’INotifyPropertyChanged en manipulant le code CIL.
4. Sauvegarder l’assembly modifié

Le transformer

Dans cette première version, imaginons quelque chose de naïf : un programme en ligne de commande, qui prend en argument le chemin de l’assembly à instrumenter :

    private static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("Usage: transformer <assembly file>");
            return;
        }
        new Transformer(path).Run();
    }

D’ailleurs, je vais continuer à être naïf en laissant de côté la gestion du logging, des exceptions, etc. Les snippets présentés ici n’en seront que plus lisibles, à défaut d’être solides.

Commençons par une vue d’ensemble des étapes nécessaires à la transformation des assemblies, que nous détaillerons ensuite. (Vous aimez les opcodes ?)

1. Chargement de l’assembly à instrumenter
2. Identification des types à modifier : on recherche ceux qui sont taggés par notre attribut [NotifyPropertyChanged]
3. Transformation de chacun de ces types pour leur faire supporter INotifyPropertyChanged
4. Sauvegarde de l’assembly modifié

Le schéma ci-dessous met en avant les différentes étapes de la transformation :

• [#1] Implémentation proprement dite de l’interface INotifyPropertyChanged
• [#2] Ajout d’une fonction “helper” pour le déclenchement de l’évènement PropertyChanged
• [#3] Instrumentation des setters, en utilisant la méthode précédente pour lancer les notifications

Voyons comment implémenter ça. Rappelez-vous, tout commence par :

	new Transformer(path).Run();

Le constructeur (qui en fait sans doute un peu trop) :

public Transformer(string assemblyPath)
{
    this.assemblyPath = assemblyPath;
    this.assembly = AssemblyFactory.GetAssembly(assemblyPath);
    this.assembly.MainModule.LoadSymbols();
    this.assembly.MainModule.FullLoad();
}

Assez trivial : on laisse tout le travail à Cecil. Son AssemblyFactory nous permet de récupérer la définition de l’assembly à modifier. Afin de conserver les sequence points et permettre de debuguer l’assembly modifiée, on charge les infos de debug. L’appel à la méthode FullLoad permet de charger en mémoire toute la représentation du module principal, afin de pouvoir la modifier par la suite.

Petite parenthèse introductive : Plusieurs fois, dans les méthodes que je vais présenter par la suite, on aura besoin de récupérer une TypeReference, à partir d’un Type. Lorsque ce sera le cas, on utilisera une des deux méthodes suivantes :

private TypeReference GetReference(Type type)
{
    TypeReference typeReference = this.assembly.MainModule.TypeReferences[type.FullName]
                                  ?? this.assembly.MainModule.Import(type);
    return typeReference;
}

private TypeReference GetReference<T>()
{
    return GetReference(typeof (T));
}

Leur fonctionnement est simple : si on a déjà chargé le type dans le module principal de l’assembly en cours de modification, on retourne directement la TypeReference correspondante, sinon on importe le type pour créer la référence. Car Cecil fait bien la distinction (qui existe au niveau CIL) entre les définitions et les références pour les différents éléments du code (types, fields, methods, etc.)

Lorsqu’on veut modifier une méthode, par exemple, on va travailler sur sa définition. Mais si on désire simplement l’appeler, il nous faut juste sa référence. Ce modèle, plus juste que celui proposé par l’API de réflexion de la BCL peut sembler troublant au premier abord, mais s’avère au final plus puissant puisqu’il colle directement avec les spécifications du langage intermédiaire. Fin de la parenthèse.

Bien, on a de quoi commencer l’autopsie du Transformer, dont le nom est plus que douteux… La méthode Run semble être un point de départ judicieux pour notre analyse :

public void Run()
{
    foreach (TypeDefinition type in GetTypesToWeave())
    {
        MethodReference firePropertyChangedMethod = WeaveINotifyPropertyChanged(type);
        WeaveEventTriggers(type, firePropertyChangedMethod);
    }
    this.assembly.MainModule.SaveSymbols();
    AssemblyFactory.SaveAssembly(this.assembly, this.assemblyPath);
}

La méthode GetTypesToWeave permet de retourner tous les types à modifier, c’est à dire ceux qui sont décorés par notre attribut [NotifyPropertyChanged]. Ce dernier devra donc être défini dans un assembly quelconque, référencé à la fois par le code client – celui qui contient les types à instrumenter – et par notre transformer. Chacun des types est ensuite transformé par les appels successifs aux méthodes WeaveINotifyPropertyChanged et WeaveEventTriggers.

La sauvegarde des modifications s’effectue elle aussi en plusieurs étapes :

• On indique qu’on souhaite conserver les symboles de debugging
• On sauvegarde notre travail en remplaçant l’assembly original par celui que l’on vient d’instrumenter.

Jusqu’ici, tout va bien, comme qui dirait. Mais creusons un peu plus. Tout d’abord, le code de la méthode GetTypesToWeave qui nous permet de retourner les types de l’assembly à modifier. Il s’agit essentiellement d’alléger la méthode Run en évitant les imbrications et en isolant la logique de recherche dans une autre méthode :

private IEnumerable<TypeDefinition> GetTypesToWeave()
{
    string attributeFullName = typeof (NotifyPropertyChangedAttribute).FullName;
    foreach (TypeDefinition type in this.assembly.MainModule.Types)
    {
        foreach (CustomAttribute attribute in type.CustomAttributes)
        {
            if (attribute.Constructor.DeclaringType.FullName == attributeFullName)
            {
                yield return type;
                break;
            }
        }
    }
}

Notez qu’on utilise pour cela un bloc itérateur. Le reste pourrait se passer de commentaire : on retourne les types marqués par l’attribut [NotifyPropertyChanged] en basant la recherche sur le fullname des attributs.

Passons maintenant à la modification des types. Rappelez-vous, il y a deux étapes principales :

• Implémentation de INotifyPropertyChanged (méthode WeaveINotifyPropertyChanged)
• Instrumentation des setters (méthode WeaveEventTriggers)

Implémentation de INotifyPropertyChanged

L’implémentation proprement dite de INotifyPropertyChanged est une tâche que l’on peut aisément redécomposer. Cette redécomposition est d’ailleurs assez visible dans la méthode WeaveINotifyPropertyChanged que je propose :

private MethodReference WeaveINotifyPropertyChanged(TypeDefinition type)
{
    TypeReference iNotifyPropertyChangedType = GetReference<INotifyPropertyChanged>();
    type.Interfaces.Add(iNotifyPropertyChangedType);
    FieldReference eventField = WeaveEvent(type);
    
    return WeaveEventFiringHelper(eventField, type);
}

La première étape consiste à récupérer une TypeReference correspondant à cette interface pour l’ajouter à la liste des interfaces du type que l’on modifie. Simple, mais insuffisant : il faut également implémenter l’interface. Dans le cas d’INotifyPropertyChanged, on doit ajouter un évènement public PropertyChanged au type. C’est la méthode WeaveEvent qui s’en chargera. (Etape [#1] du schéma)

La méthode WeaveEventFiringHelper, quant à elle, permet d’ajouter une méthode FirePropertyChanged au type. Quelque chose équivalent à :

    private void FirePropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est l’étape [#2] de la transformation, également signalée dans le schéma précédent. La référence vers cette méthode est retournée pour permettre son appel plus tard à partir des setters des propriétés.

Dès que vous aurez terminé de bailler, nous détaillerons la première étape qui consiste à ajouter l’évènement PropertyChanged au type. Soit la méthode WeaveEvent :

private FieldReference WeaveEvent(TypeDefinition type)
{
    TypeReference eventHandlerTypeRef = GetReference<PropertyChangedEventHandler>();
    MethodReference combineMethodRef = this.assembly.MainModule.Import(combineMethodBase);
    MethodReference removeMethodRef = this.assembly.MainModule.Import(removeMethodBase);
    const string eventName = "PropertyChanged";

    FieldDefinition eventField = new FieldDefinition("PropertyChanged",
                                                     eventHandlerTypeRef,
                                                     FieldAttributes.Private);
    type.Fields.Add(eventField);

    EventDefinition eventDefinition = new EventDefinition(eventName,
                                                          eventHandlerTypeRef,
                                                          0);

    eventDefinition.AddMethod = CreateEventMethod(string.Format("add_{0}", eventName),
                                                  combineMethodRef,
                                                  eventField);

    eventDefinition.RemoveMethod = CreateEventMethod(string.Format("remove_{0}", eventName),
                                                     removeMethodRef,
                                                     eventField);

    type.Methods.Add(eventDefinition.AddMethod);
    type.Methods.Add(eventDefinition.RemoveMethod);
    type.Events.Add(eventDefinition);

    return eventField;
}

Le layout n’est pas terrible, j’espère que vous ne m’en tiendrez pas rigueur.

Petit rappel : Lorsqu’on est au niveau CIL, on a une bonne visibilité sur ce qu’un langage de plus haut niveau comme C# peut nous cacher. Les évènements constituent un bon exemple. En C#, la déclaration d’un event est simple :

public event PropertyChangedEventHandler PropertyChanged;

Au niveau IL, le compilateur C# va en fait générer un champ privé encapsulé par une propriété un peu spéciale de type event qui possède les méthodes “add” et “remove“. Note : même si ce n’est pas souvent utilisé, sachez qu’à partir de C# il est possible de faire apparaitre ces méthodes pour éventuellement intercepter les abonnements / désabonnements à l’évènement.

Pour ajouter l’évènement PropertyChanged à notre type, nous avons donc :

• Ajouté un champ d’instance privé de type NotifyPropertyChangedEventHandler
• Ajouté l’évènement (pseudo propriété), qui utilise deux méthodes : add_PropertyChanged et remove_PropertyChanged
• Créé les deux méthodes précédentes, qui utilisent respectivement les méthodes statiques Delegate.Combine et Delegate.Remove pour ajouter et supprimer les handlers au champ d’instance

Puisque l’IL n’est pas très lisible, voici la traduction C# de ces deux méthodes :

public void add_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged = 
		(PropertyChangedEventHandler) Delegate.Combine(this.PropertyChanged, value);
}

public void remove_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged = 
		(PropertyChangedEventHandler) Delegate.Remove(this.PropertyChanged, value);
}

Dans notre exemple précédent, on délègue la création de ces deux méthodes à CreateEventMethod dont voici la définition :

private MethodDefinition CreateEventMethod(string methodName,
                                           MethodReference delegateMethodReference,
                                           FieldReference eventField)
{
    const MethodAttributes attributes = MethodAttributes.Public |
                                        MethodAttributes.HideBySig |
                                        MethodAttributes.Final |
                                        MethodAttributes.SpecialName |
                                        MethodAttributes.NewSlot |
                                        MethodAttributes.Virtual;

    TypeReference eventHandlerTypeRef = GetReference<PropertyChangedEventHandler>();
    TypeReference voidType = GetReference(typeof (void));

    MethodDefinition methodDef = new MethodDefinition(methodName, attributes, voidType);


    methodDef.Parameters.Add(new ParameterDefinition(eventHandlerTypeRef));
    CilWorker cilWorker = methodDef.Body.CilWorker;
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Call, delegateMethodReference);
    cilWorker.Emit(OpCodes.Castclass, eventHandlerTypeRef);
    cilWorker.Emit(OpCodes.Stfld, eventField);
    cilWorker.Emit(OpCodes.Ret);
    return methodDef;
}

Notez l’API intuitive que propose Cecil pour ce genre de choses : on instancie une définition de l’élément que l’on cherche à ajouter au type (FieldDefinition, EventDefinition, MethodDefinition, etc.), on la configure si besoin, et on l’ajoute à la définition parente. Pour ce qui est de l’émission d’IL pour le corps des méthodes, il suffit d’obtenir un CilWorker et de créer séquentiellement les instructions en utilisant les codes d’opérations du langage intermédiaire.

Voilà pour la création de l’évènement PropertyChanged. Notre type est à présent une implémentation valide de l’interface INotifyPropertyChanged, puisque qu’il respecte le contrat imposé par cette dernière : exposer un évènement PropertyChanged, de type PropertyChangedEventHandler. (Etape [#1] du schéma)

Il ne reste plus qu’à déclencher cet évènement, et pour cela, il est habituellement préférable de prévoir une méthode spécifique qui sera appellée à partir des setters (Etape [#2]). Nous l’appellons ici FireNotifyPropertyChanged et c’est la méthode WeaveEventFiringHelper de notre transformer qui se charge de l’ajouter au type instrumenté :

private MethodReference WeaveEventFiringHelper(FieldReference eventField, TypeDefinition type)
{
    MethodReference invokeMethodRef = this.assembly.MainModule.Import(invokeMethodBase);
    MethodReference argsCtorMethodRef = this.assembly.MainModule.Import(constructorMethodBase);
    TypeReference stringTypeRef = GetReference<string>();
    TypeReference voidTypeRef = GetReference(typeof (void));

    MethodDefinition firePropertyChanged = 
        new MethodDefinition("FirePropertyChanged", MethodAttributes.Private, type);
    firePropertyChanged.ReturnType = new MethodReturnType(voidTypeRef);
    ParameterDefinition propertyNameParameter =
        new ParameterDefinition("propertyName", 0, ParameterAttributes.None, stringTypeRef);
    firePropertyChanged.Parameters.Add(propertyNameParameter);

    CilWorker cilWorker = firePropertyChanged.Body.CilWorker;

    Instruction returnInstruction = cilWorker.Create(OpCodes.Ret);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Brfalse_S, returnInstruction);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Newobj, argsCtorMethodRef);
    cilWorker.Emit(OpCodes.Callvirt, invokeMethodRef);
    cilWorker.Append(returnInstruction);
    type.Methods.Add(firePropertyChanged);

    return firePropertyChanged;
}

La FieldReference récupérée en argument est celle retournée par la méthode précédente, WeaveEvent, qui a ajouté l’évènement au type. Elle représente d’ailleurs le champ de l’évènement, qui doit être utilisé pour l’invocation. La traduction C# de la méthode générée dynamiquement correspond à :

    private void FirePropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null)
        {
            this.PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est complètement équivalent au code de l’étape [#2] dans le premier schéma.

Instrumentation des setters

A ce stade, pour résumer, nous avons :

• [#1] Implémenté INotifyPropertyChanged en ajoutant un évènement PropertyChanged au type
• [#2] Créé une méthode “helper” pour déclencher l’évènement

Très logiquement, il ne reste plus qu’à appeller cette dernière à partir de tous les setters des propriétés du type que l’on modifie (étape [#3]). Cette fois-ci, on ne va pas créer un nouveau champ, un nouvel évènement ou une nouvelle méthode, on va modifier le code CIL du corps de méthodes existantes. Car un setter de propriété est une méthode traditionnelle.

Examinons la méthode WeaveEventTriggers du transformer, qui est responsable de cette tache :

private static void WeaveEventTriggers(TypeDefinition type, MethodReference firePropertyChanged)
{
    foreach (PropertyDefinition property in type.Properties)
    {
        MethodDefinition method = property.SetMethod;
        if (method == null)
        {
            continue;
        }

        Instruction retInstruction = method.Body.Instructions[method.Body.Instructions.Count - 1];

        CilWorker cilWorker = method.Body.CilWorker;
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldarg_0));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldstr, property.Name));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Call, firePropertyChanged));
    }
}

Encore une fois, l’implémentation est naïve et nous verrons s’il est possible de l’améliorer plus tard. La logique est simple :

• On itère sur toutes les propriétés du type. (Pas très malin…)
• On récupère la définition de la méthode du setter.
• On récupère une référence vers la dernière instruction du corps du setter
• On injecte le code CIL correspondant à l’appel de la méthode FirePropertyChanged avant la dernière instruction pour que la notification soit lançée à la fin de chaque modification.

En gros, si le setter en C# est du genre :

	public void set_Name(string value)
	{
		this.name = value;
	}

On le transforme en :

	public void set_Name(string value)
	{
		this.name = value;
		FirePropertyChanged("Name");
	}

Note : combineMethodBase, invokeMethodBase, constructorMethodBase et removeMethodBase, référencés dans les méthodes du Transformer, sont des membres statiques initialisés de la façon suivante :

private static readonly MethodBase combineMethodBase;
private static readonly MethodBase invokeMethodBase;
private static readonly MethodBase constructorMethodBase;
private static readonly MethodBase removeMethodBase;

static Transformer()
{
    var type = typeof (Delegate);
    combineMethodBase = type.GetMethod("Combine", new[] {type, type});
    removeMethodBase = type.GetMethod("Remove");
    type = typeof (PropertyChangedEventHandler);
    invokeMethodBase = type.GetMethod("Invoke");
    type = typeof (PropertyChangedEventArgs);
    constructorMethodBase = type.GetConstructor(new[] {typeof (string)});
}

Les MethodBase sont des types de l’API d’introspection de System.Reflection. Il est facile de récupérer les MethodReference correspondantes (API Cecil) en utilisant la méthode Import d’une ModuleDefinition.

Conclusion intermédiaire

Voilà une première version du “transformer” capable d’instrumenter un assembly existant pour faire implémenter INotifyPropertyChanged à certains de ses types automatiquement. Les améliorations possibles sont nombreuses, et je ne vais en citer que quelques unes :

• Meilleure utilisation de Cecil : après tout, je découvre et suis donc loin d’être un expert
• Meilleure intégration au process de build, en utilisant une custom task MSBuild par exemple
• Version complète de l’instrumentation : l’évènement PropertyChanged ne doit être déclenché que lorsque la valeur affectée à la propriété est différente
• Gestion des exceptions et du logging (évidemment)
• Etc.

Cecil est un outil extrêmement puissant et facile d’utilisation. Pour info, la mise en place de cette version du Transformer n’a pas dû me prendre 2 heures, alors que la femme de ma vie me parlait je faisais autre chose en même temps, et que je découvrais complètement l’API non documentée. Il est préférable par contre de connaître le CIL, même si ILdasm ou Reflector peuvent vous assister efficacement. Enfin, et presque paradoxalement, la prise en main de Cecil vous paraitra déroutante si vous avez l’habitude d’utiliser System.Reflection et System.Reflection.Emit.

Au final ma première expérience est définitivement positive, et je n’hésiterai pas dans le futur à recourir à Cecil au besoin. Je pense d’ailleurs qu’en collaboration avec une couche facilitant son utilisation dans un context post-build, on aurait quelque chose d’assez terrible, probablement plus simple à utiliser que PostSharp.Core par exemple pour des tâches bien spécifiques.

Notez tout de même que l’exemple d’utilisation de Cecil présenté ici est un peu tordu, et qu’il y a bien d’autres (meilleurs) moyens d’exploiter ses capacités.

L’AOP peut également être une solution, et peut-être même le meilleur compromis pour peu que l’on en tire partie correctement. Suite à un commentaire de Jb, j’ai essayé de voir ce que pouvait donner l’utilisation d’un tisseur statique comme PostSharp dans ce cas précis.

J’avais déjà fait auparavant quelques tests satisfaisants avec DynamicProxy de Castle, qui est un, heu, tisseur dynamique. Les contraintes m’avaient semblées être assez fortes (toujours pour résoudre la problématique de INotifyPropertyChanged) :

• Nécessité de créer un proxy pour chaque instance d’objet bindé
• Interception uniquement possible sur les propriétés virtuelles
• Performances moyennes dues au caractère dynamique des interceptions

Cela dit, en terme de concision, c’est probablement la méthode la plus efficace puisqu’en créant un StandardInterceptor d’une dizaine de lignes on pouvait s’en sortir.

Revenons à PostSharp. J’ai été impressionné, vraiment, par cet outil. Sans passer trop de temps à expliquer son fonctionnement, puisque Gael Fraiteur l’a déjà fait, sachez que le framework est un static weaver (entre autres), qui intervient en temps que post-compiler pour inspecter et modifier le code IL des assemblies résultant de la compilation. Je vous invite à consulter les ressources mises à disposition par l’auteur sur le site, elles sont assez complètes. Dans le contexte de notre problématique (oui, les notifications m’obsèdent) les avantages du tissage en post-compilation sont les suivants :

• Pas de proxy à créer au runtime pour chaque instance
• Les types sur lesquels on désire tisser l’aspect “notification-des-changements” n’ont pas besoin de respecter une quelconque convention
• Une partie du travail peut être faite durant le build process, ce qui améliore les performances au runtime.

Illustrons par le code.

Voici mon POCO (je vous conseille d’imaginer le même avec 15 propriétés) :

    public class Person
    {
        private string name;

        public string Name
        {
            get { return this.name; }
            set { this.name = value; }
        }
    }

Voici ce que je cherche à obtenir, fonctionnellement, sans avoir à écrire le code de plomberie :

    public class Person : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        private string name;

        public string Name
        {
            get { return this.name; }
            set
            {
                if (this.name != value)
                {
                    this.name = value;
                    FirePropertyChanged("Name");
                }
            }
        }

        private void FirePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

En fait, voici ce que je cherche réellement à obtenir :

    [NotifyPropertyChanged]
    public class Person
    {
        private string name;

        public string Name
        {
            get { return this.name; }
            set { this.name = value; }
        }
    }

La différence avec la première version est subtile : un attribut NotifyPropertyChanged. Je veux que tout soit transparent au niveau de mon code client. Que des instances de Person puissent être créées, ajoutées à des sources de données, modifiées comme n’importe quelles autres instances, etc.

Donc, exit le proxying, exit l’interception dynamique : ceux qui y sont habitués ont déjà compris que ce n’était pas possible. C’est là que réside la force d’un tisseur comme PostSharp (ou AspectDNG) : ils rendent possible ce genre de choses, grâce à l’approche potentiellement troublante du tissage statique.

Pour la suite de l’article, je vais simplement vous montrer une solution, et la commenter. Il ne s’agit pas d’un tutorial – mais plutôt d’une pseudo-étude de cas ayant pour but de donner un bon aperçu des capacités de PostSharp. Et accessoirement d’apaiser mon obsession.

Le principe

Utiliser PostSharp est un peu moins intuitif qu’utiliser DynamicProxy. Je vais tenter de vous exposer le principe de base de la solution.

Que faut-il pour passer d’un POCO à un POCO qui supporte INotifyPropertyChanged :

1. Implémenter l’interface du même nom : INotifyPropertyChanged, et donc, fournir un event public ayant la signature suivante : public event PropertyChangedEventHandler PropertyChanged;
2. Intercepter les accès en écriture aux propriétés, pour déclencher cet évènement PropertyChanged. Dans l’exemple donné plus haut, on va même jusqu’à tester s’il est nécessaire de déclencher l’évènement en comparant la nouvelle valeur à l’existante.

Ce sont deux choses distinctes, bien qu’on ait souvent tendance à les associer, ne serait-ce que parce que c’est logique. Mais pour bien comprendre comment utiliser l’AOP, et plus particulièrement comment concevoir l’aspect que l’on va vouloir tisser grâce à PostSharp, c’est important. Car nous allons en fait utiliser un aspect composite, formé de plusieurs sous-aspects ayant chacun un but précis.

Interception des affectations des champs privés

Ce sous-aspect, de type OnFieldAccessAspect, a un rôle facultatif : il va vérifier que la valeur que l’on cherche à affecter à un champ est différente de la valeur existante. Cela permettra de savoir si l’on doit ou non déclencher l’évènement PropertyChanged.

Implémentation de INotifyPropertyChanged

Le but de ce sous-aspect et d’implémenter INotifyPropertyChanged. PostSharp propose un CompositionAspect qui, lorsqu’il est appliqué à un type, se charge de lui faire implémenter une interface donnée en utilisant la composition et la délégation.

Le POCO implémentera bien l’interface INotifyPropertyChanged, mais les abonnements/désabonnements à son évènement PropertyChanged seront interceptés et relayés à un composant (InnerNotifier ci-dessus) implémentant également INotifyPropertyChanged. Quelque chose du genre :

    public event PropertyChangedEventHandler PropertyChanged
    {
        add { this.innerNotifier.PropertyChanged += value; }
        remove { this.innerNotifier.PropertyChanged -= value; }
    }

Le CompositionAspect a donc deux tâches :

1. Définir quelle interface le POCO doit implémenter. Une petite idée ?
2. Fournir un composant qui se chargera de la réelle logique d’implémentation de l’interface, et qui, nous le verrons plus tard, offrira également un moyen de déclencher l’évènement PropertyChanged (méthode FirePropertyChanged ci-dessus)

Interception des appels aux setters des propriétés

Ce sous-aspect a pour mission de déclencher l’évènement PropertyChanged lorsqu’un setter est appelé et que le backing field a bien été modifié. Il doit donc interagir, d’une manière ou d’une autre, avec l’aspect précédent pour déclencher l’évènement.

Il est de type OnMethodBoundaryAspect selon l’API PostSharp.

Composition de l’aspect composite

Enfin, il faut l’aspect de haut niveau, qui agrège les sous-aspects de façon cohérente pour offrir la fonctionnalité désirée. PostSharp permet la définition d’aspects composites : il suffit de créer un CompoundAspect.

La solution

Si l’approche down-top correspondait plutôt bien à l’exposition du principe de fonctionnement, je crois qu’il est plus clair ici de partir du plus haut niveau pour découvrir l’implémentation de la solution proposée.

Et le point de départ, c’est l’attribut [NotifyPropertyChanged] dont on souhaitait décorer les POCO à tisser. En voici le code :

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
[MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]
public class NotifyPropertyChangedAttribute : CompoundAspect
{
    public override void ProvideAspects(object element,
                                        LaosReflectionAspectCollection collection)
    {
        var type = (Type)element;
        collection.AddAspect(type, new ImplementINotifyPropertyChangedAspect());

        BindingFlags lookupFlags = BindingFlags.Instance
                                 | BindingFlags.Public
                                 | BindingFlags.DeclaredOnly;
        foreach (PropertyInfo propertyInfo in type.GetProperties(lookupFlags))
        {
            if (propertyInfo.CanWrite)
            {
                MethodInfo setterInfo = propertyInfo.GetSetMethod();
                collection.AddAspect(setterInfo, 
                                     new FirePropertyChangedAspect(setterInfo.Name));
            }
        }

        lookupFlags = BindingFlags.Instance
                    | BindingFlags.NonPublic
                    | BindingFlags.DeclaredOnly;
        foreach (FieldInfo fieldInfo in type.GetFields(lookupFlags))
        {
            collection.AddAspect(fieldInfo, new InterceptFieldAffectationAspect());
        }
    }
}

C’est l’aspect composé lui-même, le CompoundAspect. Analysons-le un peu plus en détails :

• Il est lui-même décoré par des attributs définissant les cibles possibles de l’aspect. Ici, on vise les types. PostSharp permet aussi l’application d’aspects par multicasting, ce qui permet de tisser des aspects sans la moindre intrusion au niveau du code à instrumenter. Concrètement, on pourrait se passer d’appliquer manuellement notre attribut [NotifyPropertyChanged] sur chaque type, et définir à la place une règle déterminant quels sont les types sur lesquels appliquer l’aspect.
• La méthode ProvideAspects est exécutée lors de la post-compilation. Elle permet de définir quels sont les sous-aspects qui composent le CompoundAspect, et sur quoi ils s’appliquent. Chaque sous-aspect doit être ajouté avec le descripteur de sa cible. Nous allons retrouver les 3 types d’aspect sus-cités :
  • Le sous aspect ImplementINotifyPropertyChangedAspect est appliqué au type de l’élément que l’on tisse.
  • Le sous aspect FirePropertyChangedAspect concerne les setters du type. On en ajoute donc une instance pour chacun d’entre eux.
  • Enfin, le sous aspect InterceptFieldAffectationAspect concerne les champs du type. On en ajoute une instance pour chacun des champs privés du type.

Regardons à quoi ressemble le premier des sous-aspects :

[Serializable]
internal class ImplementINotifyPropertyChangedAspect : CompositionAspect
{
    public override object CreateImplementationObject(InstanceBoundLaosEventArgs eventArgs)
    {
        return new InnerNotifier(eventArgs.Instance);
    }

    public override Type GetPublicInterface(Type containerType)
    {
        return typeof (INotifyPropertyChanged);
    }

    public override CompositionAspectOptions GetOptions()
    {
        return CompositionAspectOptions.GenerateImplementationAccessor;
    }
}

Ca colle assez bien avec les explications précédentes, et le code est auto commenté. Le composant implémentant réellement l’interface INotifyPropertyChanged est un InnerNotifier dont voici la définition :

[Serializable]
internal class InnerNotifier : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    private readonly object eventSender;

    private bool shouldFirePropertyChanged;

    public InnerNotifier(object eventSender)
    {
        this.eventSender = eventSender;
    }
    
    public bool ShouldFirePropertyChanged
    {
        get { return this.shouldFirePropertyChanged; }
        set { this.shouldFirePropertyChanged = value; }
    }

    public void FirePropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null && this.shouldFirePropertyChanged)
        {
            this.PropertyChanged(this.eventSender, 
                                 new PropertyChangedEventArgs(propertyName));
        }
    }
}

Là encore c’est trivial : on implémente l’interface, et on expose une méthode publique permettant de déclencher manuellement l’évènement.

C’est d’ailleurs l’aspect FirePropertyChangedAspect qui s’en chargera :

[Serializable]
public class FirePropertyChangedAspect : OnMethodBoundaryAspect
{
    private InnerNotifier notifier;
    private readonly string propertyName;

    public FirePropertyChangedAspect(string propertyName)
    {
        this.propertyName = propertyName;
    }

    public override void OnSuccess(MethodExecutionEventArgs eventArgs)
    {
        if (this.notifier == null)
        {
            var composedInteface = eventArgs.Instance as IComposed<INotifyPropertyChanged>;
            if (composedInteface != null)
            {
                this.notifier =
                    composedInteface.GetImplementation(eventArgs.InstanceCredentials)
                    as InnerNotifier;
            }
        }

        if (this.notifier != null)
        {
            this.notifier.FirePropertyChanged(this.propertyName);
        }
    }
}

La méthode OnSuccess est une des méthodes qu’il est possible de surdéfinir sur un OnMethodBoundaryAspect. Dans le flow d’interception, elle sera invoquée au runtime lorsque l’appel à la méthode cible aura réussi, donc, après que ce dernier ait eu lieu. Si vous êtes encore à me lire, vous méritez que je vous épargne les détails d’implémentation de cette méthode, mais sachez au moins qu’on récupére le InnerNotifier ayant été tissé par l’aspect ImplementINotifyPropertyChangedAspect, et que l’on appelle sa méthode FirePropertyChanged pour déclencher l’évenement en lui passant le nom de la propriété concernée.

Note: Fouillez dans la doc de PostSharp au sujet de IComposed<T> si vous voulez plus de viande, mais en gros, c’est le moyen d’exposer le composant d’un CompositionAspect (ici, notre InnerNotifier) lorsque l’option CompositionAspectOptions.GenerateImplementationAccessor a été définie. (cf. méthode GetOptions dans ImplementINotifyPropertyChangedAspect)

OK. Et non, ce n’est pas terminé, il reste bien le dernier sous-aspect utilisé pour déterminer si l’évenement PropertyChanged sera lancé ou non. J’ai nommé, InterceptFieldAffectationAspect :

[Serializable]
public class InterceptFieldAffectationAspect : OnFieldAccessAspect
{
    private InnerNotifier notifier;

    public override void OnSetValue(FieldAccessEventArgs eventArgs)
    {
        if (this.notifier == null)
        {
            var composedInteface = eventArgs.Instance as IComposed<INotifyPropertyChanged>;
            if (composedInteface != null)
            {
                this.notifier =
                    composedInteface.GetImplementation(eventArgs.InstanceCredentials)
                    as InnerNotifier;
            }
        }
        if (this.notifier != null)
        {
            this.notifier.ShouldFirePropertyChanged =
                !eventArgs.ExposedFieldValue.Equals(eventArgs.StoredFieldValue);
        }
        base.OnSetValue(eventArgs);
    }
}

Dans la méthode OnSetValue :

• On récupère une fois de plus le InnerNotifier ayant été tissé par l’aspect ImplementINotifyPropertyChangedAspect
• Si la valeur affectée au champ est égale à la valeur existante, on empêche le déclenchement de l’évènement via la propriété ShouldFirePropertyChanged du notifier.

Et voilà.

En résumé

Hum, pas vraiment un résumé, mais plutôt la séquence ayant lieu au runtime lors de la modification d’une propriété d’un objet instrumenté :

1. On s’abonne à l’évenement PropertyChanged de l’objet : ce dernier propage l’abonnement à son InnerNotifier.
2. On affecte une valeur à la propriété : le setter est appelé, mais l’interception par FirePropertyChangedAspect n’aura lieu qu’à la sortie de ce dernier.
3. Dans le corps du setter, on affecte la valeur au backing field : c’est une affectation interceptée par l’aspect InterceptFieldAffectationAspect. Si la valeur affectée est différente de celle du champ, alors il autorise le InnerNotifier à déclencher l’évènement PropertyChanged via la propriété ShouldFirePropertyChanged. Sinon, il désactive l’InnerNotifier, toujours via la propriété ShouldFirePropertyChanged.
4. A la sortie du setter, on entre dans le code d’interception de l’aspect FirePropertyChangedAspect qui, via l’InnerModifier, déclenche l’évènement PropertyChanged. Ce dernier ne sera effectivement déclenché que s’il a été laissé actif par l’InterceptFieldAffectationAspect précédemment.

Quelques remarques pour les plus courageux désoeuvrés :

• L’implémentation n’est pas une référence, et la communication entre les différents sous-aspects via le InnerNotifier n’est pas quelque chose dont je suis particulièrement fier. Mais ma connaissance de PostSharp est trop limitée actuellement pour me permettre d’envisager quelque chose de plus élégant.
• La solution peut sembler fastidieuse, mais compte tenu des spécifications (assez virtuelles, j’avoue), elle offre un bon compromis au niveau des performances : 5 fois plus lente que sans AOP, mais 5 fois plus rapide qu’une solution à base de tissage dynamique. Environ. Update : Il semblerait que dans le cas de cette implémentation les performances soient les mêmes que celles qu’on pourrait obtenir avec un tisseur dynamique.
• Au niveau de l’utilisation, c’est la forme d’AOP la plus concise et la moins intrusive possible, donc celle qui offre potentiellement le meilleur niveau d’abstraction et le meilleur gain de productivité.
• Si vous avez des alternatives, avec ou sans PostSharp, je suis preneur, évidemment.

Cet article est probablement trop chiant pour être lu jusqu’au bout, et trop spécifique pour être utile, mais il me fallait un post pour le mois d’octobre. Haha.