studio - eventos dinamicos c#

¿Por qué la implementación de eventos en C#no usa un patrón de evento débil por defecto?

Question

Esta pregunta puede conducir a respuestas especulativas, pero supongo que hay una decisión de diseño bien pensada detrás de la implementación del event en c # .

El patrón de evento en c # mantiene al suscriptor vivo mientras el editor del evento esté activo. Por lo tanto, si no cancela su suscripción, está perdiendo memoria (bueno, no tiene realmente fugas, pero la memoria permanece ocupada innecesariamente).

Si deseo evitar esto, puedo anular la suscripción a eventos o implementar un patrón de evento débil como se propone en MSDN .

Con el patrón de eventos causando tantos problemas (¿para principiantes?), La pregunta es: ¿por qué se tomó la decisión de que el editor mantenga una fuerte referencia al suscriptor, en lugar de independizarlos o permitir que los desarrolladores tengan explícitamente un modificador strong o weak ?

Ya hay un par de preguntas aquí sobre este tema y las respuestas parecen razonables, pero ninguna realmente responde por qué es así.

Answer 1

Una razón sin duda es el rendimiento . Los identificadores GC (que alimentan todas las referencias "exóticas" como WeakReference ) tienen un costo de rendimiento. Los eventos débiles son más lentos que los eventos "fuertes" ya que requieren un control de GC. Un evento fuerte se implementa (de forma predeterminada) mediante un campo de instancia que almacena un delegado. Esta es solo una referencia administrada ordinaria tan barata como cualquier otra referencia.

Se supone que los eventos son un mecanismo muy general. No son solo para situaciones de IU en las que tienes quizás unas pocas docenas de controladores de eventos. No es una buena idea obtener una gran cantidad de complejidad y costos de rendimiento en una función de lenguaje tan básica.

También hay una diferencia semántica y un no determinismo que podrían ser causados ​​por referencias débiles. Si () => LaunchMissiles() a algún evento, puede encontrar los misiles que se lanzarán solo algunas veces. Otras veces, el GC ya se ha llevado el controlador. Esto podría resolverse con identificadores dependientes que introducen otro nivel de complejidad.

Tenga en cuenta que puede implementar eventos débiles usted mismo de forma transparente para el suscriptor. Los eventos son como propiedades en el sentido de que son meras metadatos y convenciones basadas en los métodos de add y remove accesor. Así que esta es (solo) una pregunta sobre los valores predeterminados que eligieron los lenguajes .NET. Esta no es una cuestión de diseño del CLR.

Personalmente, me parece raro que la fuerte referencia a la naturaleza de los eventos sea un problema. A menudo, los eventos se conectan entre objetos que tienen una vida útil igual o muy similar. Por ejemplo, puede conectar eventos todo lo que desee en el contexto de una solicitud HTTP en ASP.NET porque todo será elegible para la recopilación cuando la solicitud haya finalizado. Cualquier filtración tiene un límite de duración corta.