问观察者、发布/订阅和数据绑定之间的区别

EN

以下是我对这三个问题的看法：

数据绑定

本质上，这仅仅意味着“对象Y上的属性X的值在语义上绑定到对象B上的属性A的值。没有关于Y如何知道或被提供对象B上的变化的假设。

观察者，或可观察者/观察者

一种设计模式，通过该模式，对象具有通知其他对象特定事件的能力-通常是使用实际事件完成的，这有点像对象中具有特定函数/方法形状的插槽。观察者是提供通知的人，观察者接收这些通知。在.net中，观察者可以公开事件，观察者使用“事件处理程序”形状的钩子订阅该事件。没有关于通知发生的具体机制的假设，也没有关于一个观察者可以通知的观察者数量的假设。

发布/订阅

可观察/观察者模式的另一个名称(可能具有更多的“广播”语义)，通常意味着更“动态”的风格-观察者可以订阅或取消订阅通知，一个观察者可以向多个观察者“喊出”。在.NET中，可以使用标准事件来实现这一点，因为事件是MulticastDelegate的一种形式，因此可以支持将事件交付给多个订阅者，还可以支持取消订阅。发布/订阅在某些上下文中的含义略有不同，通常涉及事件和事件之间更多的“匿名性”，这可以通过任何数量的抽象来促进，通常涉及一些认识所有各方的“中间人”(例如消息队列)，但单独的各方并不了解对方。

数据绑定，Redux

在许多“类MVC”模式中，可观察对象公开某种方式的“属性更改通知”，其中还包含有关更改的特定属性的信息。观察者是隐式的，通常由框架创建，并通过一些绑定语法订阅这些通知，以明确地标识对象和属性，而“事件处理程序”只是复制新值，潜在地触发任何更新或刷新逻辑。

数据绑定Redux

数据绑定的另一种实现？好吧，这里有一个很愚蠢的问题：

• 启动后台线程，不断检查对象的绑定属性。
• 如果该线程检测到该属性值在上次检查后发生了更改，请将该值复制到绑定的项中。

观察者/可观察者模式和发布者/订阅者模式之间有两个主要区别：

1. Observer/Observable模式主要是以同步的方式实现的，即当某个事件发生时，可观察对象调用其所有观察者的适当方法。Publisher/Subscriber模式主要是以异步方式实现的(使用消息队列)。

1. 在Observer/Observable模式中，观察者知道可观察到的。然而，在Publisher/Subscriber，中，发布者和订阅者不需要知道彼此的。它们只是在消息队列的帮助下进行通信。

正如您正确地提到的，数据绑定是一个通用术语，它可以使用观察者/观察者或发布者/订阅者方法来实现。数据是发布者/可观察者。

让我感到有点好笑的是，这里的所有答案都试图解释观察者模式和发布/订阅模式之间的细微差别，而没有给出任何具体的例子。我敢打赌，大多数读者仍然不知道如何通过读取一个是同步的，另一个是异步的来实现每一个。

需要注意的一件事是：这些模式的目标是尝试解耦代码

观察者是一种设计模式，其中对象(称为主题)维护依赖于它的对象(观察者)的列表，自动通知它们状态的任何更改。

这意味着observable object有一个列表，其中保存了它的所有observers(通常是函数)。并且可以遍历这个列表并在它觉得合适的时候调用这些函数。

详情请参见this observer pattern示例。

当您想要监听对象上的任何数据更改并相应地更新其他UI视图时，此模式非常有用。

但是Cons是可观测的，只维护一个用于保持观察者的数组(在本例中，该数组是observersList)。

它不区分update是如何触发的，因为它只有一个notify function，用来触发存储在该数组中的所有函数。

如果我们想要根据不同的事件对观察者处理程序进行分组。我们只需要将该observersList修改为如下所示的Object

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

详情请参见this pubsub example。

人们称这种变体为pub/sub。因此，您可以根据发布的events触发不同的函数。