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


163

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

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

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

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


Я нашел другой: грязная проверка, что делает Angular.js. Более подробная информация здесь: stackoverflow.com/questions/9682092/databinding-in-angularjs
Джесс

Ответы:


143

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

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

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

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

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

Pub / Sub

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

Связывание данных, Redux

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

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

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

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

Я ценю ваш ответ и пытаюсь реализовать другую идею связывания данных.
Джесс

@ jessemon хех, нет проблем; шаблон наблюдателя, безусловно, является «абстрактно лучшим» подходом, который я знаю, но мой ужасный маленький пример также «связывает данные», хотя и хаотично и неэффективно.
JerKimball

7
Честно говоря, я устала слышать "паб / суб ака шаблон наблюдателя", они совсем не одно и то же. Pub / sub - это система событий, шаблон наблюдателя использует систему событий для публикации событий АВТОМАТИЧЕСКИ при изменении объекта. Если вы вручную генерируете события, когда меняете объект, вы не используете шаблон наблюдателя.
BT

154

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

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

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

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


7
Я читал веб-приложения JavaScript от O'Reilly ( shop.oreilly.com/product/0636920018421.do ). В главе 2 Алекс реализует pub/subиспользование событий JS. Это реализация обратного вызова, но это синхронный пример.
Джесс,

5
Я не читал книгу, но если бы она была реализована с использованием «событий» JS, она была бы асинхронной, поскольку по определению события асинхронные.
Param

3
Привет, Джесс, конечно, ты прав. Не существует стандартного определения для этих терминов 😊
Парам

14
Обычно наблюдаемая имеет список наблюдателей (она перебирает этот список, чтобы отправить событие всем). Издатель, как правило, знает только об очереди, в которой он публикует свои события / сообщения. Он не знает, сколько потребителей подписалось на эту очередь.
Парам

7
Для меня это принципиальное различие между ними: Кроме того, в схеме наблюдателей наблюдатели знают о наблюдаемом. Принимая во внимание, что в Pub / Sub ни издатели, ни потребители не должны знать друг друга. Они просто общаются с помощью очередей сообщений. Отличный ответ!
maryisdead

23

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

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

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

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

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

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

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

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

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

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

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

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

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


Ну, это гораздо лучший, краткий и четкий ответ. :)
CoderX

На высоком уровне я всегда говорил, что саб-паб - это образец наблюдателя, но со всем, что имеет разные вкусы.
Мрачное

9

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

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

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.