Appliquer l'AOP

Question

J'utilise certaines solutions de style AOP de base pour des problèmes transversaux tels que la sécurité, la journalisation, la validation, etc. Ma solution a évolué autour de Castle Windsor et DynamicProxy. J'ai suivi cette voie parce que je peux tout appliquer à l'aide d'un DSL basé sur Boo et garder mon code propre d'attributs. Le week-end dernier, on m'a demandé de regarder PostSharp car il est supposé être un "meilleur" Solution. J'ai jeté un coup d'œil à PostSharp, mais l'utilisation des attributs m'a découragé.

Quelqu'un at-il essayé les deux solutions et souhaiterait-il partager ses expériences?

Answer 1

J'ai seulement regardé Castle-Windsor pendant une courte période, donc je ne peux pas en parler, mais j'ai utilisé la post-charge.

Postsharp fonctionne par tissage au moment de la compilation. Il ajoute une étape de post-compilation à votre construction où il modifie votre code. Le code est compilé comme si vous veniez de programmer les problèmes transversaux dans votre code. C'est un peu plus performant que le tissage à l'exécution et, grâce à l'utilisation d'attributs, PostSharp est très facile à utiliser. Je pense que l'utilisation d'attributs pour AOP n'est pas aussi problématique que son utilisation pour DI. Mais ce n’est que mon goût personnel.

Mais ...

Si vous utilisez déjà Castle pour l’injection de dépendances, je ne vois pas pourquoi on ne devrait pas l’utiliser également pour les contenus AOP. Je pense que bien que l'AOP au moment de l'exécution soit un peu plus lent qu'au moment de la compilation, il est également plus puissant. AOP et DI sont des concepts liés, donc je pense que c'est une bonne idée d'utiliser un seul framework pour les deux. Donc, je vais probablement regarder à nouveau le contenu du château du prochain projet dont j'ai besoin d'AOP.

Answer 2

Quelques problèmes mineurs avec PostSharp ...

Un problème que j'ai rencontré avec PostSharp est que, tout en utilisant asp.net, les numéros de ligne pour les messages d'exception sont "out" en fonction du nombre d'instructions IL injectées dans les sous-ensembles par PostSharp, car les PDB ne sont pas également injectés: - ).

De plus, sans les assemblys PostSharp disponibles au moment de l'exécution, des erreurs d'exécution se produisent. En utilisant Windsor, les coupes transversales peuvent être désactivées ultérieurement sans recompilation du code.

(espérons que cela a du sens)