ALT.Net sur l’AOP

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 🙂

Publicités

3 réflexions sur “ALT.Net sur l’AOP

  1. Vivement la réunion,

    je pense que ceux qui ne savent pas trop ce qu’il se cache derrière l’AOP l’utilisent sans le savoir (comme bien souvent).

    une bonne partie du framework .net utilise les méta attributs pour injecter/générer du comportement au runtime (sérialisation, wcf),

    c’est aussi très vrai avec les frameworks opensource pour les problématiques transverses
    – frameworks web/mvc/rest avec AcceptVerbs, ModelBinder, ReturnBinder, Filter etc.
    – framework de services (gestion transaction, audit)
    – ORM la c’est vraiment net qu’il y’a des aspects tramés 😉

    bref, sans être un maître de l’AOP, on peut en tirer parti efficacement et étendre leur fonctionnalités pour réduire le bruit dans le code

    Vivement la réunion!

  2. Oui, merci Gauthier pour tes remarques!

    Par contre, je voudrai apporter une correction à mon post d’après les commentaires de Romain: AspectDNG n’a pas besoin du code, il tisse directement à partir de l’IL (post-compilation).

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s