Разница между Observer, Pub/Sub и привязкой данных

В чем разница между шаблоном наблюдателя, публикацией/подпиской и привязкой данных?

Я немного обыскал Qaru и не нашел хороших ответов.

Я пришел к выводу, что привязка данных - это общий термин, и существуют разные способы его реализации, такие как шаблон наблюдателя или шаблон публикации/подписки. С помощью шаблона Observer Observable обновляет свои Observers. С помощью Pub/Sub 0 издателей могут публиковать сообщения определенных классов, а 0 подписчиков могут подписываться на сообщения определенных классов.

Существуют ли другие способы реализации "привязки данных"?

+146
источник поделиться
5 ответов

Вот мой взгляд на три:

Привязка данных

По сути, в основе это просто означает, что "значение свойства X в объекте Y семантически связано со значением свойства A в объекте B. Не делается никаких предположений относительно того, как Y знает или передает изменения в объекте B.

Наблюдатель, или Наблюдаемый/Наблюдатель

Шаблон проектирования, с помощью которого объект наделен способностью уведомлять других о конкретных событиях - как правило, выполняется с использованием реальных событий, которые являются своего рода слотами в объекте в форме определенной функции/метода. Наблюдаемым является тот, кто предоставляет уведомления, а наблюдатель получает эти уведомления. В .net наблюдаемая может представлять событие, и наблюдатель подписывается на это событие с помощью крючка в форме "обработчика события". Не делается никаких предположений ни о конкретном механизме, по которому происходят уведомления, ни о количестве наблюдателей, которых может наблюдать один наблюдатель.

Pub/Sub

Другое имя (возможно, с более "широковещательной" семантикой) паттерна Observable/Observer, которое обычно подразумевает более "динамический" аромат - наблюдатели могут подписываться или отказываться от подписки на уведомления, а один наблюдаемый может "кричать" нескольким наблюдателям. В .NET для этого можно использовать стандартные события, поскольку события являются формой MulticastDelegate, и поэтому могут поддерживать доставку событий нескольким подписчикам, а также поддерживать отмену подписки. Pub/Sub имеет немного другое значение в определенных контекстах, обычно включающее в себя больше "анонимности" между событием и четным числом, чему может способствовать любое количество абстракций, обычно включающее некоторого "среднего человека" (такого как очередь сообщений), который знает все стороны, но отдельные стороны не знают друг о друге.

Привязка данных, Redux

Во многих "MVC-подобных" шаблонах наблюдаемое предоставляет некоторый способ "уведомления об изменении свойства", который также содержит информацию о конкретном измененном свойстве. Наблюдатель неявный, обычно создаваемый платформой, и подписывается на эти уведомления с помощью некоторого синтаксиса привязки для конкретной идентификации объекта и свойства, а "обработчик событий" просто копирует новое значение, потенциально вызывая любое обновление или логику обновления.

Привязка данных к Redux

Альтернативная реализация для привязки данных? Хорошо, вот глупый

  • запускается фоновый поток, который постоянно проверяет привязанное свойство объекта.
  • если этот поток обнаруживает, что значение свойства изменилось со времени последней проверки, скопируйте значение в связанный элемент.
+125
источник

Существуют два основных различия между шаблонами Observer/Observable и Publisher/Subscriber:

  • Шаблон Observer/Observable в основном реализуется с помощью синхронного способа, т.е. наблюдаемый вызывает соответствующий метод для всех своих наблюдателей при возникновении какого-либо события. Шаблон Издатель/Подписчик в основном реализуется с помощью асинхронного способа (с использованием очереди сообщений).

  • В шаблоне Наблюдатель/Наблюдаемый наблюдатели знают о наблюдаемом. Принимая во внимание, что в Publisher/Subscriber издателям и подписчикам не нужно знать друг друга. Они просто общаются с помощью очередей сообщений.

Как вы упомянули правильно, привязка данных является общим термином и может быть реализована с использованием метода Observer/Observable или Publisher/Subscriber. Данные - это Publisher/Subscriber.

+142
источник

Я немного удивлен, что все ответы здесь пытались объяснить тонкую разницу между шаблонами Observer и Pub/Sub без каких-либо конкретных примеров. Бьюсь об заклад, большинство читателей до сих пор не знают, как реализовать каждый из них, читая один синхронно, а другой асинхронно.

Стоит отметить, что целью этих шаблонов является попытка отделить код

Observer - это шаблон проектирования, в котором объект (известный как субъект) поддерживает список объектов в зависимости от него (наблюдателей), автоматически уведомляя их о любых изменениях состояния.

Образец наблюдателя

Это означает, что observable object имеет список, в котором он хранит всех своих observers (которые обычно являются функциями). и может пройти этот список и вызвать эти функции, когда он чувствует себя хорошо.

см. этот пример шаблона наблюдателя для деталей.

Этот шаблон хорош, когда вы хотите прослушать любое изменение данных на объекте и соответственно обновить другие представления пользовательского интерфейса.

Но минусы - это наблюдаемые, которые поддерживают только один массив для хранения наблюдателей (в этом примере массив - observersList).

Он НЕ различает способ запуска обновления, поскольку у него есть только одна notify function, которая запускает все функции, хранящиеся в этом массиве.

Если мы хотим сгруппировать обработчики наблюдателей на основе разных событий. Нам просто нужно изменить этот список observersList на Object типа

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

см. этот пример pubsub для деталей.

и люди называют эту вариацию как pub/sub. Таким образом, вы можете запускать различные функции в зависимости от опубликованных вами events.

+17
источник

Я согласен с вашим выводом об обоих шаблонах, тем не менее, для меня я использую Observable, когда я нахожусь в одном процессе, и я использую Pub/Sub в межпроцессных сценариях, где все стороны знают только общий канал, но не стороны,

Я не знаю других шаблонов, или позвольте мне сказать так, мне никогда не требовались другие шаблоны для этой задачи. Даже большинство сред MVC и реализации привязки данных обычно используют концепцию наблюдателя.

Если вы заинтересованы в межпроцессном взаимодействии, я рекомендую вам:

"Корпоративные шаблоны интеграции: проектирование, создание и развертывание решений для обмена сообщениями" - http://www.addison-wesley.de/9780321200686.html

Эта книга содержит множество идей о том, как отправлять сообщения между процессами или классами, которые можно использовать даже в задачах внутрипроцессного взаимодействия (это помогло мне программировать в более свободной форме).

Надеюсь, это поможет!

+9
источник

В схеме наблюдателя вещание осуществляется непосредственно от наблюдаемого к наблюдателям, чтобы они "знали" друг друга. Но при использовании шаблона Pub/Sub существует третий компонент, называемый брокером сообщений, который известен как издателю, так и подписчику.

0
источник

Посмотрите другие вопросы по меткам или Задайте вопрос