Différence entre Observer, Pub/Sub et Data Binding

Question

Quelle est la différence entre le Modèle d'observateur , Publier/S'abonner et Liaison de données ?

J'ai cherché un peu sur Stack Overflow et je n'ai pas trouvé de bonnes réponses.

J'en suis venu à penser que la liaison de données est un terme générique et qu'il existe différentes manières de la mettre en œuvre, telles que le modèle de l'observateur ou le modèle Pub/Sub. Avec le modèle Observer, un Observable met à jour ses Observateurs. Avec Pub/Sub, 0-many publishers peut publier des messages de certaines classes et 0-many subscribers peut s'abonner à des messages de certaines classes.

Existe-t-il d'autres modèles de mise en œuvre de la "liaison de données" ?

Answer 1

Il existe deux différences majeures entre les modèles observateur/observable et éditeur/abonné :

1. Observateur/Observable est le plus souvent mis en œuvre dans un synchrone c'est-à-dire que l'observable appelle la méthode appropriée de tous ses observateurs lorsqu'un événement se produit. L'observable Éditeur/abonné est le plus souvent mis en œuvre dans un asynchrone (en utilisant une file d'attente de messages).

2. Dans le cadre de la Observateur/Observable le modèle les observateurs sont conscients de l'observable . Considérant qu'en Éditeur/abonné , les éditeurs et les souscripteurs n'ont pas besoin de se connaître . Ils communiquent simplement à l'aide de files d'attente de messages.

Comme vous l'avez mentionné à juste titre, la liaison de données est un terme générique qui peut être mis en œuvre à l'aide d'une méthode observateur/observable ou éditeur/abonné. Les données sont le Publisher/Observable.

Answer 2

Voici mon point de vue sur les trois :

Liaison de données

Essentiellement, cela signifie simplement que "la valeur de la propriété X sur l'objet Y est sémantiquement liée à la valeur de la propriété A sur l'objet B. Aucune hypothèse n'est faite quant à la façon dont Y connaît ou est informé des changements sur l'objet B.".

Observateur, ou Observable/Observateur

Un modèle de conception par lequel un objet est doté de la capacité de notifier à d'autres des événements spécifiques - généralement en utilisant des événements réels, qui sont en quelque sorte des fentes dans l'objet avec la forme d'une fonction/méthode spécifique. L'observable est celui qui fournit les notifications, et l'observateur reçoit ces notifications. En .net, l'observable peut exposer un événement et l'observateur s'abonne à cet événement à l'aide d'un crochet en forme de "gestionnaire d'événement". Aucune hypothèse n'est faite sur le mécanisme spécifique par lequel les notifications se produisent, ni sur le nombre d'observateurs qu'un observable peut notifier.

Pub/Sub

Un autre nom (peut-être avec une sémantique plus "broadcast") du modèle Observable/Observer, qui implique généralement une saveur plus "dynamique" - les observateurs peuvent s'abonner ou se désabonner aux notifications et un observable peut "crier" à plusieurs observateurs. En .NET, on peut utiliser les événements standard pour cela, puisque les événements sont une forme de MulticastDelegate, et peuvent donc prendre en charge la livraison d'événements à de multiples abonnés, ainsi que la désinscription. Pub/Sub a une signification légèrement différente dans certains contextes, impliquant généralement plus d'"anonymat" entre l'événement et l'auteur de l'événement, ce qui peut être facilité par un certain nombre d'abstractions, impliquant généralement un "intermédiaire" (tel qu'une file d'attente de messages) qui connaît toutes les parties, mais les parties individuelles ne se connaissent pas les unes les autres.

Liaison de données, Redux

Dans de nombreux modèles de type MVC, l'observable expose une sorte de "notification de changement de propriété" qui contient également des informations sur la propriété spécifique modifiée. L'observateur est implicite, généralement créé par le cadre, et s'abonne à ces notifications via une syntaxe de liaison permettant d'identifier spécifiquement un objet et une propriété, et le "gestionnaire d'événements" se contente de copier la nouvelle valeur, en déclenchant éventuellement une logique de mise à jour ou de rafraîchissement.

Liaison de données re Redux

Une implémentation alternative pour la liaison de données ? Ok, en voici une stupide :

• un thread d'arrière-plan est lancé pour vérifier en permanence la propriété bound d'un objet.
• si ce thread détecte que la valeur de la propriété a changé depuis la dernière vérification, il copie la valeur dans l'élément lié.

Answer 3

Je suis un peu amusé par le fait que toutes les réponses tentent d'expliquer la différence subtile entre les modèles Observer et Pub/Sub sans donner d'exemples concrets. Je parie que la plupart des lecteurs ne savent toujours pas comment implémenter chacun d'entre eux en lisant que l'un est synchrone et l'autre asynchrone.

Une chose est à noter : L'objectif de ces modèles est d'essayer de découpler le code

L'observateur est un modèle de conception dans lequel un objet (appelé sujet) maintient une liste d'objets qui dépendent de lui (observateurs), les informant automatiquement de tout changement d'état.

Modèle d'observateur

Cela signifie qu'un observable object dispose d'une liste dans laquelle il conserve tous ses observers (qui sont généralement des fonctions). et peut parcourir cette liste et invoquer ces fonctions lorsqu'il le juge opportun.

voir ce modèle d'observateur pour plus de détails.

Ce modèle est utile lorsque vous souhaitez écouter tout changement de données sur un objet et mettre à jour d'autres vues de l'interface utilisateur en conséquence.

Mais les inconvénients sont Les observables ne conservent qu'un seul tableau pour les observateurs. (dans l'exemple, le tableau est observersList ).

Il ne différencie PAS la manière dont la mise à jour est déclenchée car il n'a qu'une seule notify function qui déclenche toutes les fonctions stockées dans ce tableau.

Si nous voulons regrouper les gestionnaires d'observateurs en fonction de différents événements. Il nous suffit de modifier ce observersList à un Object comme

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

voir cet exemple de pubsub pour plus de détails.

et les gens appellent cette variante pub/sub . Vous pouvez donc déclencher différentes fonctions en fonction de la events vous avez publié.

Answer 4

Je suis d'accord avec votre conclusion sur les deux modèles, néanmoins, en ce qui me concerne, j'utilise Observable lorsque je suis dans le même processus et j'utilise Pub/Sub dans les scénarios inter-processus, où toutes les parties ne connaissent que le canal commun mais pas les parties.

Je ne connais pas d'autres modèles, ou plutôt, je n'ai jamais eu besoin d'autres modèles pour cette tâche. Même la plupart des frameworks MVC et des implémentations de data binding utilisent généralement en interne le concept d'observateur.

Si vous êtes intéressé par la communication inter-processus, je vous le recommande :

"Modèles d'intégration d'entreprise : Concevoir, construire et déployer des solutions de messagerie" - https://www.enterpriseintegrationpatterns.com/

Ce livre contient de nombreuses idées sur la manière d'envoyer des messages entre processus ou des classes qui peuvent être utilisées même dans des tâches de communication intra-processus (il m'a aidé à programmer d'une manière plus lâche).

J'espère que cela vous aidera !

Answer 5

Une différence concrète est qu'un Observable est toujours engagé lorsqu'un observateur ne veut plus observer. Mais un abonné peut mettre fin à son abonnement et l'éditeur ne sera jamais informé de son intention de se désabonner.