Quelles sont les différences entre LinFu.DynamicProxy et Castle.DynamicProxy ?

Question

J'envisage d'ajouter une logique à une bibliothèque sur laquelle je travaille et qui nécessiterait l'utilisation d'un mandataire dynamique. J'aimerais avoir l'avis d'utilisateurs qui ont utilisé ces deux bibliothèques dans un environnement de production. Est-ce que l'une est plus performante que l'autre, y avait-il des défauts qui vous ont poussé à passer à l'autre, etc. En gros, racontez-moi vos expériences avec les bibliothèques. Les réponses m'aideront à décider laquelle utiliser.

-- Editer --

---

J'ai oublié de mentionner que la bibliothèque que je développe sera compatible avec Mono. Par conséquent, toute connaissance que vous pouvez partager sur les deux bibliothèques et leur compatibilité avec Mono serait également très appréciée.

Answer 1

Je suis un committer de Castle, qui contribue à Dynamic Proxy, donc je suis peut-être partial, mais je pense généralement que le Dynamic Proxy de Castle est une bien meilleure solution. Je parle ici de LinFu DynamicProxy v1.0 car c'est ce que je connais. LinFu.Proxy 2 est basé sur Mono.Cecil et est réécrit à partir de zéro.

• Castle couvre un plus large éventail de scénarios.
• Castle dispose d'une base d'utilisateurs (beaucoup) plus importante et a fait ses preuves dans de nombreuses applications OSS et commerciales.
• Castle a en fait de meilleures performances ( lien )
• Castle dispose d'une API plus propre et plus facile à utiliser par exemple, invoquer une méthode cible à Castle DynamicProxy ressemble à ceci :

invocation.Proceed();

pour LinFu, cela ressemble à ceci (le nom réel de la méthode/propriété peut varier car je l'écris de mémoire)

//invocation.TargetMethod is MethodInfo, so you're using reflection
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters);

• Castle dispose d'un groupe d'utilisateurs actif où vous pouvez obtenir rapidement des réponses à vos questions.

Le problème de performance, mentionné par l'autre réponse, n'est pas un problème de DynamicProxy, mais le résultat d'un bogue dans l'implémentation de BCL par Microsoft (sous Mono, ce problème n'existe pas). Ce problème ne se manifeste que lorsque vous avez plusieurs (plus de 200+) types de proxy dans un seul ModuleScope.

La solution est triviale - ne générez pas autant de types de proxy (en général, vous n'aurez pas à le faire) ou utilisez plusieurs ModuleScopes/ProxyGenerators (par exemple, Rhino.Mocks utilise cette approche).

Personnellement, je ne développe pas sur Mono, donc je n'ai pas d'expérience de première main, mais il y a des bibliothèques qui utilisent Castle DP sur Mono, et nous n'avons pas eu de compliments, donc je suppose que cela fonctionne très bien.

Depuis mon benchmark il y a quelques mois, il n'y a pas eu de nouvelle version de Castle DP (la nouvelle version est prévue pour la fin de l'année). LiFu a une version 2.0, mais je ne suis pas sûr qu'elle soit seulement un tronc ou qu'elle soit publiée. Je ne sais pas pour Spring ou Unity.

Answer 2

Linfu est un générateur de proxy plus léger que le générateur de proxy Castle.

Pour décider lequel utiliser, pour être honnête, cela ne fait pas une grande différence.

D'après l'auteur, le Linfu surpasse largement le générateur Castle, mais d'après mes propres observations de l'utilisation réelle, la différence de vitesse est marginale.

Cela dit, Linfu est plus performant que Castle, et je ne suis pas au courant de ce que Castle a de plus, c'est pourquoi j'utilise toujours Linfu.

Answer 3

Nous avons eu quelques problèmes de perforation liés à LinFu vs Castle dans la 2.0.1. http://niemware.blogspot.com/2009/11/nhibernate-21-performance-issues-with.html