2008-10-02 10 views
0

Il y a quelques années, j'ai lu un livre décrivant comment remplacer l'implémentation par défaut de l'expéditeur dans .NET par votre propre processeur.Création de votre propre boucle de traitement d'événements .NET personnalisée

class foo { 
     public event EventHandler myEvent; 
     ... 
    } 

    ... 
     myFoo.myEvent += myBar1.EventHandler; 
     myFoo.myEvent += myBar2.EventHandler; 

Chaque fois que l'événement se déclenche, les deux gestionnaires myBar1 et myBar2 seront appelés. Si je me souviens, l'implémentation par défaut de cette boucle utilise une liste chaînée et itère simplement sur la liste et appelle les délégués EventHandler dans l'ordre.

Ma question est double:

  1. Quelqu'un sait quel livre je lisais?
  2. Pourquoi voudriez-vous remplacer l'implémentation par défaut (qui pourrait être répondue dans le livre)?

Edit: Le livre que je faisais allusion était en effet le CLR de Jeffrey Richter via C#

Répondre

8

Cela aurait pu être l'un des nombreux livres ou articles sur le Web.

Il y a diverses raisons pour lesquelles vous pourriez vouloir changer la façon dont les événements sont abonnés/désabonnement:

  • Si vous avez de nombreux événements, dont beaucoup peuvent bien ne pas être souscrites, vous pouvez utiliser EventHandlerList à à réduire la consommation de mémoire
  • Vous pouvez vous connecter abonnement/désabonnement
  • Vous pouvez utiliser une référence faible pour éviter d'être liée à la vôtre la vie de l'abonné
  • Vous pouvez modifier le verrouillage associé à des sous-marins cription/désabonnement

Je suis sûr qu'il ya plus - ce sont du haut de ma tête :)

EDIT: Notez également qu'il ya une différence entre avoir une manière personnalisée de gérer l'abonnement/désabonnement et avoir un moyen personnalisé de déclencher l'événement (qui peut appeler GetInvocationList et garantir que tous les gestionnaires sont appelés, indépendamment des exceptions, par exemple).

2

me semble me rappeler quelque chose de similaire dans le CLR de Jeffrey Richter via C#. Edit: Je me souviens vraiment qu'il va dans les détails à ce sujet.

Il existe plusieurs raisons différentes de prendre le contrôle de l'enregistrement d'événement. L'un d'eux est de réduire le gonflement du code lorsque vous avez des tonnes d'événements. Je pense que Jeffrey a cela en détail dans le livre ...

1
  1. Pas
  2. Vous pouvez, par exemple, ont besoin de briser la chaîne d'appel en fonction du résultat de l'un des gestionnaires. Supposons que votre objet CustomEventArgs possède une propriété 'Blocked', qui, lorsqu'elle est définie sur true, supprime toutes les autres invocations de gestionnaire d'événements.
Questions connexes