2009-09-10 22 views
30

Estoy buscando agregar lógica a una biblioteca en la que estoy trabajando que requeriría la necesidad de un Dynamic Proxy. Me gustaría obtener algunos consejos de los usuarios que han utilizado estas dos bibliotecas en un entorno de producción. ¿Uno desempeña el otro, hubo alguna deficiencia que hizo que tengas que cambiar al otro, etc. Básicamente dime tus experiencias con la biblioteca. Las respuestas me ayudarán a decidir cuál usar.¿Cuáles son las diferencias entre LinFu.DynamicProxy y Castle.DynamicProxy?

- Editar -


me olvidó mencionar que la biblioteca que estoy desarrollando apoyará Mono, por lo tanto, cualquier conocimiento que pueden compartir acerca de las dos bibliotecas y su apoyo para Mono Sería muy bueno también.

Respuesta

20

Soy un committer de Castle, contribuyendo al 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 está basado en Mono.Cecil y se reescribe desde el principio.

  • Castle cubre una amplia gama de escenarios.
  • Castillo tiene (mucho) más grande base de usuarios, y se ha demostrado en muchas aplicaciones comerciales OSS y
  • Castillo es en realidad un mejor desempeño (link)
  • Castillo tiene más limpio, más fácil de usar API por ejemplo, método de destino invocando a Castillo DynamicProxy se ve así:

invocation.Proceed();

para Linfu, parece que esto (nombre real método/propiedad puede variar a medida que lo estoy escribiendo desde la memoria)

//invocation.TargetMethod is MethodInfo, so you're using reflection 
invocation.TargetMethod.Invoke(invocation.Target,invocation.Parameters); 
  • Castillo tiene un grupo de usuarios activos donde se puede obtener respuestas rápidas a las preguntas.

El problema de rendimiento, mencionado por la otra respuesta no es un problema de DynamicProxy, pero es el resultado de un error en la implementación de BCL por parte de Microsoft (en Mono no existe dicho problema). 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 tantos tipos de proxy (generalmente no será necesario) o use muchos ModuleScopes/ProxyGenerators (por ejemplo, Rhino.Mocks usa 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 solo multa.

Desde mi punto de referencia hace unos meses, no ha habido una nueva versión 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.

+0

@Krzysztof - Gracias por el enlace en las pruebas de rendimiento que ha ejecutado. Veo que las pruebas fueron hace aproximadamente 6 meses. ¿Has intentado ejecutar las pruebas de nuevo con las últimas versiones de cada marco? No estoy seguro de si ha habido nuevas versiones desde entonces. Además, olvidé una cosa en mi pregunta y la edité. ¿Podría editar su respuesta para incluir las pruebas de experiencia bajo Mono? –

+0

He realizado pruebas de Dynamic Proxy (trunk) en comparación con la versión 2.1. Si bien los tiempos de intercepción no han cambiado (y funciona ** muy ** rápido), la generación del tipo de proxy ahora es varias veces más rápida –

+0

@ KrzysztofKoźmic, ¿Cuál sería su recomendación actual entre Castle y Lin Fu? – smartcaveman

10

Linfu es un generador de proxy más liviano que el generador de proxy de Castle.

Al decidir cuál usar, para ser honesto, no hace mucha diferencia.

De acuerdo con el autor, Linfu superará en gran medida al generador de Castle, pero en mis propias observaciones del uso en el mundo real, la diferencia de velocidad es marginal.

Habiendo dicho que Linfu superará a Castle, y no estoy al tanto de nada que Castle tenga sobre él, así que siempre uso Linfu.

+1

¿Qué quiere decir con 'peso ligero'? –

+1

Por peso liviano me refiero a menos código, ensamblaje más pequeño y (OK, posiblemente según cómo lo use) más rápido. – Cocowalla

+0

@Cocowalla - ¿Está utilizando la última versión basada en Mono.Cecil. Además, ¿puedes compartir experiencias ejecutando LinFu en Mono? –

Cuestiones relacionadas