.net - ¿Cuáles son las diferencias entre LinFu.DynamicProxy y Castle.DynamicProxy?
castle-dynamicproxy linfu-dynamicproxy (3)
Estoy considerando agregar lógica a una biblioteca en la que estoy trabajando que requeriría la necesidad de un Proxy dinámico. Me gustaría obtener algunos consejos de los usuarios que han utilizado estas dos bibliotecas en un entorno de producción. ¿Uno supera al otro? ¿Hubo algún inconveniente que hizo que tuvieras que cambiar al otro? Básicamente, cuéntame tus experiencias con la biblioteca. Las respuestas me ayudarán a decidir cuál usar.
- Editar -
Olvidé mencionar que la biblioteca que estoy desarrollando será compatible con Mono, por lo tanto, cualquier conocimiento que pueda compartir sobre las dos bibliotecas y su soporte para Mono también sería excelente.
Soy un interlocutor de Castle, contribuyendo a Dynamic Proxy, por lo que puedo ser parcial, pero en general creo que el proxy dinámico de Castle es una solución mucho mejor. Estoy hablando aquí de LinFu DynamicProxy v1.0 porque eso es con lo que estoy familiarizado. LinFu.Proxy 2 se basa en Mono.Cecil y se reescribe desde cero.
- Castle cubre una amplia gama de escenarios.
- Castle tiene (mucho) una base de usuarios más grande, y está probado en muchas aplicaciones OSS y comerciales.
- Castle en realidad se está desempeñando mejor ( link )
- Castle tiene una API más limpia y fácil de usar, por ejemplo, invocar el método de destino para Castle DynamicProxy tiene el siguiente aspecto:
invocation.Proceed();
para LinFu, se ve así (el método / nombre de propiedad real puede variar a medida que lo escribo desde la memoria)
//invocation.TargetMethod is MethodInfo, so you''re using reflection
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters);
- Castle tiene un grupo de usuarios activo en el que puede obtener rápidamente respuestas a sus preguntas.
El problema de rendimiento, mencionado en la otra respuesta, no es un problema de DynamicProxy, pero es el resultado de un error en la implementación de BCL de Microsoft (en Mono no hay tal problema, por cierto). Esto solo se manifiesta cuando tiene muchos (más de 200) tipos de proxy en un único ModuleScope.
La solución es trivial: no genere muchos tipos de proxy (generalmente no será necesario) o use muchos ModuleScopes / ProxyGenerators (por ejemplo, Rhino.Mocks utiliza este enfoque)
Personalmente no desarrollo en Mono, así que no tengo experiencia de primera mano, sin embargo, hay bibliotecas que usan Castle DP en Mono, y no obtuvimos ninguna compliant así que supongo que funciona muy bien.
Desde mi punto de referencia hace unos meses, no ha habido un nuevo lanzamiento de Castle DP (la nueva versión está destinada a finales de año). LiFu tiene una versión 2.0, pero no estoy seguro de si es solo troncal o está liberado. No sé sobre Primavera o Unidad.
Tuvimos algunos problemas relacionados con LinFu vs Castle en 2.0.1. http://niemware.blogspot.com/2009/11/nhibernate-21-performance-issues-with.html
Linfu es un generador proxy más ligero que el generador proxy Castle.
Al decidir cuál usar, para ser honesto, no hay mucha diferencia.
Según el autor, Linfu superará en gran medida al generador del castillo, pero en mis propias observaciones del uso en el mundo real, la diferencia en la velocidad es marginal.
Habiendo dicho que Linfu superará a Castle, y no conozco nada de lo que Castle tiene, y por eso siempre uso Linfu.