Разница между Observer, Pub/Sub и привязкой данных
В чем разница между шаблоном наблюдателя, публикацией/подпиской и привязкой данных?
Я немного обыскал Qaru и не нашел хороших ответов.
Я пришел к выводу, что привязка данных - это общий термин, и существуют разные способы его реализации, такие как шаблон наблюдателя или шаблон публикации/подписки. С помощью шаблона Observer Observable обновляет свои Observers. С помощью Pub/Sub 0 издателей могут публиковать сообщения определенных классов, а 0 подписчиков могут подписываться на сообщения определенных классов.
Существуют ли другие способы реализации "привязки данных"?
Ответы
Ответ 1
Вот мой взгляд на три:
Привязка данных
По сути, в основе это просто означает, что "значение свойства X в объекте Y семантически связано со значением свойства A в объекте B. Не делается никаких предположений относительно того, как Y знает или передает изменения в объекте B.
Наблюдатель, или Наблюдаемый/Наблюдатель
Шаблон проектирования, с помощью которого объект наделен способностью уведомлять других о конкретных событиях - как правило, выполняется с использованием реальных событий, которые являются своего рода слотами в объекте в форме определенной функции/метода. Наблюдаемым является тот, кто предоставляет уведомления, а наблюдатель получает эти уведомления. В .net наблюдаемая может представлять событие, и наблюдатель подписывается на это событие с помощью крючка в форме "обработчика события". Не делается никаких предположений ни о конкретном механизме, по которому происходят уведомления, ни о количестве наблюдателей, которых может наблюдать один наблюдатель.
Pub/Sub
Другое имя (возможно, с более "широковещательной" семантикой) паттерна Observable/Observer, которое обычно подразумевает более "динамический" аромат - наблюдатели могут подписываться или отказываться от подписки на уведомления, а один наблюдаемый может "кричать" нескольким наблюдателям. В .NET для этого можно использовать стандартные события, поскольку события являются формой MulticastDelegate, и поэтому могут поддерживать доставку событий нескольким подписчикам, а также поддерживать отмену подписки. Pub/Sub имеет немного другое значение в определенных контекстах, обычно включающее в себя больше "анонимности" между событием и четным числом, чему может способствовать любое количество абстракций, обычно включающее некоторого "среднего человека" (такого как очередь сообщений), который знает все стороны, но отдельные стороны не знают друг о друге.
Привязка данных, Redux
Во многих "MVC-подобных" шаблонах наблюдаемое предоставляет некоторый способ "уведомления об изменении свойства", который также содержит информацию о конкретном измененном свойстве. Наблюдатель неявный, обычно создаваемый платформой, и подписывается на эти уведомления с помощью некоторого синтаксиса привязки для конкретной идентификации объекта и свойства, а "обработчик событий" просто копирует новое значение, потенциально вызывая любое обновление или логику обновления.
Привязка данных к Redux
Альтернативная реализация для привязки данных? Хорошо, вот глупый
- запускается фоновый поток, который постоянно проверяет привязанное свойство объекта.
- если этот поток обнаруживает, что значение свойства изменилось со времени последней проверки, скопируйте значение в связанный элемент.
Ответ 2
Существуют два основных различия между шаблонами Observer/Observable и Publisher/Subscriber:
-
Шаблон Observer/Observable в основном реализуется с помощью синхронного способа, т.е. наблюдаемый вызывает соответствующий метод для всех своих наблюдателей при возникновении какого-либо события. Шаблон Издатель/Подписчик в основном реализуется с помощью асинхронного способа (с использованием очереди сообщений).
-
В шаблоне Наблюдатель/Наблюдаемый наблюдатели знают о наблюдаемом. Принимая во внимание, что в Publisher/Subscriber издателям и подписчикам не нужно знать друг друга. Они просто общаются с помощью очередей сообщений.
Как вы упомянули правильно, привязка данных является общим термином и может быть реализована с использованием метода Observer/Observable или Publisher/Subscriber. Данные - это Publisher/Subscriber.
Ответ 3
Я немного удивлен, что все ответы здесь пытались объяснить тонкую разницу между шаблонами Observer и Pub/Sub без каких-либо конкретных примеров. Бьюсь об заклад, большинство читателей до сих пор не знают, как реализовать каждый из них, читая один синхронно, а другой асинхронно.
Стоит отметить, что целью этих шаблонов является попытка отделить код
Observer - это шаблон проектирования, в котором объект (известный как субъект) поддерживает список объектов в зависимости от него (наблюдателей), автоматически уведомляя их о любых изменениях состояния.
Образец наблюдателя
Это означает, что observable object
имеет список, в котором он хранит всех своих observers
(которые обычно являются функциями). и может пройти этот список и вызвать эти функции, когда он чувствует себя хорошо.
см. этот пример шаблона наблюдателя для деталей.
Этот шаблон хорош, когда вы хотите прослушать любое изменение данных на объекте и соответственно обновить другие представления пользовательского интерфейса.
Но минусы - это наблюдаемые, которые поддерживают только один массив для хранения наблюдателей (в этом примере массив - observersList
).
Он НЕ различает способ запуска обновления, поскольку у него есть только одна notify function
, которая запускает все функции, хранящиеся в этом массиве.
Если мы хотим сгруппировать обработчики наблюдателей на основе разных событий. Нам просто нужно изменить этот список observersList
на Object
типа
var events = {
"event1": [handler1, handler2],
"event2": [handler3]
}
см. этот пример pubsub для деталей.
и люди называют эту вариацию как pub/sub
. Таким образом, вы можете запускать различные функции в зависимости от опубликованных вами events
.
Ответ 4
Я согласен с вашим выводом об обоих шаблонах, тем не менее, для меня я использую Observable, когда я нахожусь в одном процессе, и я использую Pub/Sub в межпроцессных сценариях, где все стороны знают только общий канал, но не стороны,
Я не знаю других шаблонов, или позвольте мне сказать так, мне никогда не требовались другие шаблоны для этой задачи. Даже большинство сред MVC и реализации привязки данных обычно используют концепцию наблюдателя.
Если вы заинтересованы в межпроцессном взаимодействии, я рекомендую вам:
"Корпоративные шаблоны интеграции: проектирование, создание и развертывание решений для обмена сообщениями" - http://www.addison-wesley.de/9780321200686.html
Эта книга содержит множество идей о том, как отправлять сообщения между процессами или классами, которые можно использовать даже в задачах внутрипроцессного взаимодействия (это помогло мне программировать в более свободной форме).
Надеюсь, это поможет!
Ответ 5
В схеме наблюдателя вещание осуществляется непосредственно от наблюдаемого к наблюдателям, чтобы они "знали" друг друга. Но при использовании шаблона Pub/Sub существует третий компонент, называемый брокером сообщений, который известен как издателю, так и подписчику.