Некоторый опыт применения подхода «по большей части» в крупномасштабном продукте:
Модель: Узлы создают дерево 1: N, т. Е. Каждый компонент (кроме корня) имеет 1 родителя и 1..N потомков. Данные передаются почти исключительно от родителей к детям. Уведомления об изменениях могут отправляться с любого узла в дереве.
Реализация: Все листья уведомляются с помощью идентификатора отправляющего узла и счетчика «генерации». Листья знают, от какого пути узла они зависят, поэтому они знают, нужно ли им обновляться. (Любой другой алгоритм обновления дочерних узлов тоже подойдет, и мог бы быть лучше в ретроспективе).
Листья запрашивают у своих родителей текущие данные, запрос всплывает рекурсивно. Счетчик генерации включен, поэтому всплывающее окно останавливается на исходном узле.
Преимущества:
- родительским узлам не нужно много / никакой информации о своих дочерних узлах. Данные могут быть использованы кем угодно - это позволило использовать общий подход к реализации некоторых (изначально не ожидаемых) функций, не связанных с пользовательским интерфейсом, поверх данных, предназначенных для отображения
- Дочерние узлы могут агрегировать и задерживать обновления (избегая перекрашиваний, безусловно, лучше, чем быстрое рисование)
- неактивные листья вообще не вызывают трафика данных
Недостатки :
- Инкрементные обновления дороги, так как полные данные публикуются.
Реализация фактически позволяет запрашивать разные пакеты данных (и
счетчик генерации может предотвратить ненужный трафик данных), но изначально разработанные пакеты данных очень велики. Нарезка их была запоздалой мыслью, но работает нормально.
- Вам нужен действительно хороший механизм генерации. Первоначально реализованное столкнулось с начальными обновлениями (которые требуют специальной обработки - см. «Инкрементные обновления») и агрегацией обновлений
- необходимость перемещения данных вверх дерево было сильно недооценено.
- Публикация дешева, только если узел предлагает доступ только для чтения к текущим данным. Для этого может потребоваться дополнительная синхронизация обновлений, хотя
- иногда требуется обновить промежуточные узлы, даже если все листья неактивны
- некоторые листы в итоге реализовали опрос, некоторые базовые узлы в конечном итоге полагались на это. некрасиво.
В целом:
Data-Pull кажется мне более естественным, когда уровень данных и обработки ничего не должен знать об интерфейсе пользователя. Однако для предотвращения «Обновления юниверса» требуется сложный механизм уведомлений об изменениях.
Data-Push упрощает пошаговые обновления, но только если отправитель близко знает получателя.
У меня нет опыта подобного масштаба при использовании других моделей, поэтому я не могу дать рекомендации. Оглядываясь назад, я вижу, что я в основном использовал тягу, что было меньше хлопот. Было бы интересно увидеть опыт других людей.