Різниця між спостерігачами, паб / підкамерами та прив'язкою даних

Яка різниця між шаблоном спостерігача , публікацією / підпискою та прив'язкою даних ?

Я трохи обшукав Stack Overflow і не знайшов хороших відповідей.

Я вважаю, що прив'язка даних - це загальний термін, і існують різні способи їх застосування, такі як Шаблон спостерігача або Шаблон Pub / Sub. За допомогою шаблону спостерігача спостерігач оновлює своїх спостерігачів. З Pub / Sub, 0-багато видавців можуть публікувати повідомлення певних класів, а 0-багато підписників можуть передплачувати повідомлення певних класів.

Чи існують інші зразки здійснення "прив'язки даних"?

Ось мій погляд на три:

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

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

Спостерігач, або Спостережуваний / Спостерігач

Шаблон дизайну, за допомогою якого об'єкт пронизаний можливістю сповіщати інших про конкретні події - зазвичай це робиться за допомогою фактичних подій, які схожі на слоти в об'єкті у формі певної функції / методу. Спостерігаючий - це той, хто надає сповіщення, а спостерігач отримує ці сповіщення. У .net спостережуваний може викрити подію, і спостерігач підписується на цю подію гачком у формі "обробника подій". Ніяких припущень щодо конкретного механізму дії сповіщень не робиться, ні про кількість спостерігачів, які один спостережуваний може повідомити.

Паб / Під

Інша назва (можливо, з більшою кількістю «трансляційною» семантикою) шаблону «Спостережуваний / Спостерігач», що зазвичай передбачає більш «динамічний» аромат - спостерігачі можуть підписатись або скасувати підписку на сповіщення, а один спостережуваний може «викрикнути» декількома спостерігачами. У .NET, для цього можна використовувати стандартні події, оскільки події є формою MulticastDelegate, і тому вони можуть підтримувати доставку подій для декількох підписників, а також підтримувати підписку. Pub / Sub має дещо інше значення у певних контекстах, зазвичай передбачає більше "анонімності" між подією та вечором, що може бути полегшене будь-якою кількістю абстракцій, як правило, із залученням якогось "середнього чоловіка" (наприклад, черги повідомлень), який знає всіх партії, але окремі сторони не знають один про одного.

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

У багатьох моделях, подібних до MVC, спостережувані виявляють певний спосіб "повідомлення про зміну властивості", який також містить інформацію про певну зміну властивості. Спостерігач неявний, зазвичай створюється рамкою, і підписується на ці сповіщення через якийсь прив'язуючий синтаксис, щоб спеціально ідентифікувати об'єкт і властивість, а "обробник подій" просто копіює нове значення, потенційно викликаючи будь-яку логіку оновлення або оновлення.

Зв'язування даних повторно

Альтернативна реалізація для прив'язки даних? Гаразд, ось дурний:

• запускається фонова нитка, яка постійно перевіряє пов'язане властивість на об'єкті.
• якщо цей потік виявляє, що значення властивості змінилося з часу останньої перевірки, скопіюйте це значення на прив'язаний елемент.

Існують дві основні відмінності між моделями спостерігачів / спостережуваних та видавців / підписників:

1. Шаблон спостерігача / спостереження здебільшого реалізується синхронно , тобто спостерігається викликає відповідний метод усіх своїх спостерігачів, коли відбувається якась подія. Видавець / Підписчик модель в основному реалізована в асинхронному способі ( з використанням черги повідомлень).

2. У шаблоні спостерігача / спостереження спостерігачі знають про спостережуване . В той час, як у видавця / передплатнику , видавцям та підписникам не потрібно знати один одного . Вони просто спілкуються за допомогою черг повідомлень.

Як ви сказали правильно, прив'язка даних є загальним терміном, і його можна реалізувати, використовуючи метод спостерігача / спостережуваного або видавця / підписника. Дані - видавець / підписник.

Мене трохи дивує, що всі відповіді тут намагалися пояснити тонку різницю між шаблонами Observer та Pub / Sub, не надаючи конкретних прикладів. Надіюсь, більшість читачів досі не знають, як реалізувати кожного, читаючи один синхронно, а другий - асинхронно.

Варто зазначити одне: мета цих моделей - намагання розв'язати код

Спостережник - це схема дизайну, коли об’єкт (відомий як суб'єкт) підтримує список об'єктів залежно від нього (спостерігачів), автоматично повідомляючи їх про будь-які зміни стану.

Шаблон спостерігача

Це означає, observable objectщо у списку є список, де він зберігає всі свої функції observers(які зазвичай є функціями). і може пройти цей список і викликати ці функції, коли відчуває себе добре.

див. цей приклад шаблону спостерігача для деталей.

Цей шаблон хороший, коли ви хочете прослухати будь-яку зміну даних про об’єкт та оновити інші представлення інтерфейсу відповідно.

Але Мінуси " Оглядові" підтримують лише один масив для утримання спостерігачів (у прикладі масив є observersList).

Він НЕ розрізняє, як відбувається оновлення, оскільки воно має лише одне notify function , яке запускає всі функції, що зберігаються в цьому масиві.

Якщо ми хочемо згрупувати обробників спостерігачів на основі різних подій. Нам просто потрібно змінити це observersListна Objectподібне

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

див. цей приклад pubsub для детальної інформації.

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

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

Я не знаю інших зразків, або дозвольте сказати так, мені ніколи не потрібні інші зразки для цього завдання. Навіть більшість фреймворків MVC та реалізації прив'язки даних зазвичай використовують внутрішньо концепцію спостерігача.

Якщо ви зацікавлені в міжпроцесорному спілкуванні, рекомендую:

"Шаблони інтеграції підприємств: проектування, створення та розгортання повідомлень" - http://www.addison-wesley.de/9780321200686.html

Ця книга містить безліч ідей щодо того, як надсилати повідомлення між процесами чи класами, які можна використовувати навіть у внутрішньопроцесових комунікаційних завданнях (це допомогло мені програмувати у більш зв'язаному вигляді).

Я сподіваюся, що це допомагає!