Je vous invite à venir à la session ALT.Net sur l’AOP présenté par Romain Verdier le Mercredi 17 juin.
Pour vous mettre dans le bain et vous permettre de vous informer sur le sujet avant la réunion, voici un exemple d’AOP super simple avec Postsharp : http://bit.ly/71pej
Dans le cadre de mon projet actuel, l’AOP aurait pu m’aider à décorer les méthodes qui nécessitent de l’impersonation (accès à des ressources critiques qui nécessite donc un compte privilégié) ou à gérer la sécurité+log+erreurs au niveau des WebServices (CheckClientCertificate+Log+SoapException).
J’utilise souvent l’AOP avec Spring.net, qui utilise la méthode « création de proxy dynamiquement » ou appelé aussi « dynamic weaving ».
Cette méthode consiste à créer des proxy dynamiquement qui encapsulent l’objet cible en ajoutant le code des aspects aux bons endroits. La limite de l’approche avec Spring.Net est que l’on perd en performance à la création de ces proxy, on ne peut exposer qu’une seule interface, et cela oblige à utiliser Spring.net pour se faire injecter l’instance.
Postsharp lui, fait tout à la compilation, c’est ce que l’on appelle le « static weaving ». L’avantage est que l’on gagne en performance, on ne dépend pas de la façon d’instancier la classe, et la manière d’ajouter des aspects se fait par code (par attributs) se qui peut s’avérer plus agréable que de les déclarer dans un XML (ce que fait Spring.net). L’inconvénient est que cela oblige à posséder le code source de l’objet à « aspectiser » et de le compiler avec les aspects.
On peut citer AspectDNG qui utilise aussi le « static weaving ».
Aspect# utilise le « dynamic weaving » tout comme Spring.net. Ils utilisent tous la réflexion à l’aide de System.Reflection.Emit (fourni par défaut avec .Net) pour créer les proxy dynamiquement. Aspect# le fait par l’intermédiaire de Castle.DynamicProxy (utilisé aussi par NHibernate ou RhinoMock).
Le débat à la session ALT.Net va certainement porter sur Réflexion vs Introspection: la réflexion est moins bonne en performance que l’introspection, car elle nécessite de charger tout le code en mémoire, alors que l’introspection analyse directement l’IL. Voici un petit post sur le débat: http://bit.ly/2xq6aB
Romain a travaillé sur Mono.Cecil.Decompiler avec Jean-Baptiste Evain, il va donc sans doute nous parler des avantages de l’introspection avec Mono.Cecil. Voici un autre post sur le sujet sur le blog de JB.
Voila, j’espère que vous serez ainsi mieux armés pour assister à la session 🙂