Pourquoi * devrions-nous utiliser EventHandler

Je déteste EventHandler. Je déteste devoir faire appel à l’ sender si je veux faire quelque chose avec. Je déteste le fait que je EventArgs créer une nouvelle classe héritant de EventArgs pour utiliser EventHandler .

On m’a toujours dit EventHandler est la tradition et bla, bla … peu importe. Mais je ne trouve pas de raison pour laquelle ce dogme existe toujours.

Y a-t-il une raison pour laquelle ce serait une mauvaise idée de nommer un nouveau délégué:

 delegate void EventHandler(TSender sender, T args);

De cette façon, l’ sender sera typescript et je peux transmettre tout ce que je veux comme arguments (y compris EventArgs personnalisé si je le souhaite).

Il existe en fait une bonne raison pour exiger que le deuxième argument dérive de EventArgs si votre code entièrement sécurisé héberge du code tiers comme partiellement sécurisé.

Étant donné que le rappel au délégué de gestion des événements est effectué dans le contexte du code généré et non du code tiers, il est possible pour du code tiers malveillant d’append une opération système privilégiée en tant que gestionnaire d’événements et ainsi potentiellement exécuter une escalade de attaque de privilège en exécutant du code dans votre contexte entièrement sécurisé que leur contexte partiellement sécurisé n’a pas pu être exécuté.

Par exemple, si vous déclarez un gestionnaire comme étant de type int -> void le code tiers pourrait alors mettre en YourEvent += Enviroment.Exit(-1) attente YourEvent += Enviroment.Exit(-1) et vous YourEvent += Enviroment.Exit(-1) quitter le processus par inadvertance. Cela poserait évidemment un problème facile à détecter, mais il y a beaucoup plus d’API malveillantes qui pourraient être mises en queue pour faire autre chose.

Lorsque la signature est (object, EventArgs) -> void , aucune opération privilégiée dans la structure ne peut être mise en queue car aucune d’entre elles n’est compatible avec cette signature. Cela fait partie de l’examen du code de sécurité dans la structure (malheureusement, je ne trouve pas la source où j’ai lu cela).

Par conséquent, dans certaines circonstances, il existe des problèmes de sécurité sérieux quant à l’utilisation du modèle standard. Si vous êtes sûr à 100% que votre code ne sera jamais utilisé dans ces circonstances, le guide de signature d’événement n’est pas aussi important (à l’exception des autres développeurs qui pensent à WTF), mais si c’est le cas, vous devriez le suivre.

Il n’ya aucune raison de l’utiliser, à part sa convention .net acceptée, et toute personne qui lit votre code devrait le comprendre assez facilement. Pour cela c’est une bonne raison.

Cependant, c’est votre code et vous pouvez décider de ce qui vous convient le mieux. Bien sûr, lorsque vous interagissez avec le fcl, vous devrez le faire à l’aide de gestionnaires d’événements.

J’utilise couramment les types Action<...> comme gestionnaires d’événements. Si vous n’avez pas besoin d’interopérabilité avec un autre code (ou un concepteur) nécessitant spécifiquement un EventHandler , vous n’avez aucune raison de l’utiliser.

Bien, faire tout ce casting est inhabituel, le code client sait assez souvent déjà qui est l’ expéditeur parce qu’il a explicitement souscrit l’événement pour un seul object. Le partage de gestionnaires d’événements est assez rare. Si un comportement courant est souhaitable, la meilleure approche consiste à dériver de la classe et à remplacer la méthode OnXxxx. Vous ne vous souciez alors plus de l’ expéditeur , vous avez ceci .

Toutefois, résolvez votre problème de manière sortingviale en incluant une référence de type sécurisée à l’expéditeur dans votre classe dérivée EventArgs personnalisée.

Je suis d’accord avec vous, la convention est stupide et / ou obsolète. Faites-le correctement, avec le bon type de sécurité et les génériques.

Cela revient tout le temps que vous avez une tâche à faire, et vous pouvez suivre la façon dont le dernier l’a fait OU le faire d’une autre manière que vous pensez probablement meilleure.

Le premier choix est généralement choisi – faites-le comme le dernier, et vous n’aurez pas de problèmes. Mais le deuxième choix est ce qui améliore les logiciels sur le long terme. (Ou du moins, cela PEUT l’améliorer, si vous avez raison, votre façon de faire est meilleure! :))

Comme Preet Sangha l’a dit, la raison pour laquelle créer un tel délégué serait une mauvaise idée est que les autres développeurs pourraient se demander pourquoi vous le faites de cette manière.

Utilisation du délégué EventHandler est une recommandation présentée ici: http://msdn.microsoft.com/en-us/library/ms229011.aspx