Modèle de conception observateur et modèle de délégué d'événement C#

Question

Il semble que le modèle de conception de l'observateur soit intégré dans C# par le biais de son modèle de délégué d'événement. Y a-t-il une raison pour laquelle je devrais l'implémenter de manière classique ?

salutations
123Developer

Answer 1

En général, le modèle d'événement intégré au langage sera suffisant pour le modèle d'observateur. Il n'y a vraiment aucune raison de l'implémenter d'une manière différente, puisque vous ne faites que recréer des événements.

Ceci étant dit, il est rare que les gens changent le modèle d'événement "standard". Par exemple, j'ai vu des cas où les gens veulent déclencher des événements de manière asynchrone. Je ne le recommande généralement pas (personnellement, je pense qu'il est préférable de gérer cela du côté de l'abonné), mais cela peut toujours être géré via un événement C# standard, mais la levée de l'événement change légèrement (utilisation de GetInvocationList et appel asynchrone des délégués).

Answer 2

Vous avez raison. Le modèle de l'observateur est mis en œuvre dans le système d'événements de C#, en utilisant des délégués.

la raison n°1 pour laquelle vous voudriez quelque chose de plus proche d'un observateur classique est même l'agrégation pour faciliter les événements de domaine et/ou les architectures d'applications composites.

jeremy miller a publié un excellent article sur l'agrégateur d'événements : http://codebetter.com/blogs/jeremy.miller/archive/2009/07/21/braindump-on-the-event-aggregator-pattern.aspx

et j'ai utilisé son post pour créer mon agrégateur d'événements que j'ai intégré dans une architecture basée sur la messagerie pour mes applications winforms / handheld : http://www.lostechies.com/blogs/derickbailey/archive/2009/12/22/understanding-the-application-controller-through-object-messaging-patterns.aspx

Answer 3

Je pense qu'en général, il n'y a pas de raison réelle de ne pas utiliser le modèle délégué de C# pour mettre en œuvre le modèle Observer. Mais, dans .Net 4, ils ont ajouté IObserver<T> y IObservable<T> des interfaces pour mettre en œuvre un système de notification basé sur le push. Je suppose donc que c'est l'un des cas où il est préférable d'utiliser les interfaces plutôt que le modèle basé sur les événements.

Answer 4

Je suis d'accord pour dire que les gestionnaires d'événements de .NET répondent à la plupart de vos besoins en matière de modèle d'observation. Cependant, il existe quelques interfaces que vous devez connaître, en particulier pour Silverlight et WPF. Il s'agit de INotifyPropertyChanged et INotifyCollectionChanged. Elles prescrivent des modèles spécifiques que Silverlight et WPF attendent pour la liaison de données. Il existe également une classe ObservableCollection qui implémente INotifyCollectionChanged, ce qui évite bien des tracas lors de la création d'interfaces Silverlight et WPF.

Answer 5

Je suis d'accord pour dire que le modèle de conception classique de l'observateur est grandement simplifié en C#. Je pense qu'il existe probablement des cas où il est plus "sûr" d'utiliser l'implémentation classique. Les choses qui me viennent à l'esprit sont le multithreading et les API publiques. Je pense que les tests unitaires peuvent parfois être plus faciles si vous utilisez la méthode classique. Mais, comme vous l'avez mentionné, il existe maintenant un raccourci beaucoup plus facile avec les délégués C#. Désolé, je n'ai pas de réponse définitive sur les cas où vous devez utiliser le modèle classique.