Application AOP

Question

J'ai utilisé des solutions de base de type AOP pour des problèmes transversaux tels que la sécurité, la journalisation, la validation, etc. Ma solution a porté sur Castle Windsor et DynamicProxy. Je suis allé dans cette voie parce que je peux appliquer tout en utilisant un DSL basé sur Boo et garder mon code propre des attributs. On m'a dit le week-end de jeter un oeil à PostSharp car c'est supposé être une "meilleure" solution. J'ai jeté un rapide coup d'œil sur PostSharp, mais j'ai été rebuté par l'utilisation de l'attribut.

Est-ce que quelqu'un a essayé les deux solutions et voudrait partager ses expériences?

Answer 1

J'ai seulement regardé Castle-Windsor pour une courte période (encore), donc je ne peux pas commenter mais j'ai utilisé postsharp. Postsharp fonctionne par tissage au moment de la compilation. Il annonce une étape post-compilation à votre build où il modifie votre code. Le code est compilé comme si vous venez de programmer les préoccupations transversales dans votre code. C'est un peu plus performant que le tissage en cours d'exécution et en raison de l'utilisation des attributs Postsharp est très facile à utiliser. Je pense que l'utilisation d'attributs pour AOP n'est pas aussi problématique que l'utilisation de DI. Mais c'est juste mon goût personnel.

Mais ...

Si vous utilisez déjà le château pour l'injection de dépendance, je ne vois pas une bonne raison pour laquelle vous ne devriez pas utiliser aussi pour des choses AOP. Je pense que l'AOP à l'exécution est un peu plus lent qu'à la compilation, mais il est aussi plus puissant. AOP et DI sont à mon avis des concepts liés, donc je pense que c'est une bonne idée d'utiliser un cadre pour les deux. Donc, je vais probablement regarder les choses du château à nouveau le projet suivant j'ai besoin d'AOP.

Answer 2

quelques problèmes mineurs avec PostSharp ...

Une question que j'ai eu avec PostSharp est que tout en utilisant asp.net, les numéros de ligne pour les messages d'exception sont « out » par le nombre d'instructions IL injecté dans asssemblies par PostSharp car les PDB ne sont pas injectés aussi bien :-).

De même, sans les assemblys PostSharp disponibles au moment de l'exécution, des erreurs d'exécution se produisent. En utilisant Windsor, les raccourcis peuvent être désactivés à une date ultérieure sans recompiler le code.

(espérons que cela est logique)