Тема: [PureMVC] PureMVC Медиаторы
Показать сообщение отдельно
Старый 30.10.2013, 01:00
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 16  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Цитата:
Сообщение от alatar
в любом случае, для каждого экземпляра вида, создается отдельный экземпляр соответствующего ему медиатора.
Абсолютно не согласен, ибо считаю что один медиатор вполне способен обслуживать несколько однотипных видов. И именно в этом для меня и есть преимущество наличия такого класса как медиатор. Иначе он бесполезная прослойка.

Цитата:
Сообщение от alatar
Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.
Опять же не согласен.
Есть к примеру медиатор попапов. То что зарегистрировалось в фасаде пусть там и висит, есть не просит.
(в угоду производительности конечно можно разные варианты применять, но регистрация/дерегистрация медиаторов, команд, прокси в пюре - часто тупой оверхед ненужный). А вот сами виды - да, можно прятать, дестроить, что угодно с ними делать. Но опять же. Без предыдущего утверждения - этот момент будет не всегда оправдан. Т.е. если медиатор == вью-обжект - тогда как бы придется регистрировать или убирать. Но ЗАЧЕМ????

//******************
Итого:
Команда - одна команда ОДНО действие с ОДНИМ уровнем абстракции, с ОДНИМ срезом логики. Пишет данные в прокси. Слушает нотификации кликов и прочей мути из медиаторов.
Прокси - один прокси умеет работать с НЕСКОЛЬКИМИ дата-обжектами. Через паблик методы принимает данные от команд. Шлет нотификации медиаторам.
Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам.

Медиаторы, прокси, команды - зарегистрировал один раз и пусть живут. Если есть необходимость их убирать из фасада - скорее всего архитектура косая. (Я не беру в учет супер круто написанный проект в котором везде вместо i++ - стоит ++i и прочая муть, и все-равно для оптимизации производителоьности вот прямо ппц как необходимо это сделать). Если не для производительности а по логике - нафиг такую логику.

Добавлено через 7 минут
И еще один момент меня колбасит ппц как.
То что вы юзаете пюре абсолютно не значит что ВСЁ должно быть наследниками классов пюре.
Регистрацию команд или медиаторов проще вынести в отдельный какой-то менеджер.
А дерево медиаторов это имхо просто опа неподдерживаемая.
__________________
Кто к нам с чем для чего - тот у нас того от того.


Последний раз редактировалось Dukobpa3; 30.10.2013 в 01:12.