PureMVC Медиаторы

[namespaces]

Сообщение от alatar

Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.

Я так понял вы советуете регистрировать все медиаторы в команде, а не в одном главном медиаторе не?

Сообщение от PainKiller

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

А в самом классическом MVC, разве не создается для каждого объекта своя вьюха, контроллер, модель и т.д.?

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

[PainKiller]

А в самом классическом MVC, разве не создается для каждого объекта своя вьюха, контроллер, модель и т.д.?

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

[namespaces]

Сообщение от PainKiller

везде по разному,

Представим так, есть 5 кнопок и все эти кнопки имеют свой слушатель клик, я их создаю и кидаю на сцену в отдельном классе. Потом создаю Медиатор для этого класса, регистрирую все 5 событий которые могут посылать кнопки и переключаюсь через switch выполняя команды.

override public function handleNotification(note:INotification):void
		{
			switch (note.getName())
			{
				case AppFacade.OPEN_WINDOW: 
					viewComponent.addChild(window);
					Cookie.setCookie("OPEN_WINDOW", 10);
					break;
 
				case AppFacade.CLOSE_WINDOW: 
					viewComponent.removeChild(window);
					Cookie.setCookie("CLOSE_WINDOW", 11);
					break;
 
				case AppFacade.EFFECT_WINDOW: 
					Cookie.setCookie("EFFECT_WINDOW", 12);
					break;
 
				case AppFacade.TRANSITION_IN: 
					Cookie.setCookie("TRANSITION_IN", 13);
					break;
 
				case AppFacade.TRANSITION_OUT: 
					Cookie.setCookie("TRANSITION_OUT", 14);
					break;
 
			}
		}

Правильно делать так? Если управлять все эти спрайты через один Медиатор и обмениваться 20-30 сообщениями, по моему что то не так(
К тому же, при удалении спрайта из Медиатора, сам компонент все еще висит в памяти.
Если удалить таким образом

viewComponent.removeChild(window);

Добавлено через 5 часов 9 минут
Ах да! По моему начинаю понимать что к чему.
На каждую вьюшку (компонент) создаю свой медиатор, то есть даже одна кнопочка сама по себе не может участвовать в фреймворке без посредника - медиатора. Это прежде всего полезно тем, что мы можем в будущем менять кнопки (классы) как хотим, без затрагивания всего кода и инициализация пройдет автоматически с заранее подготовленным медиатором.
И что самое интересное, штатные оповещения (dispatchEvent) используются только внутри вьюшек (компонентов) и нигде больше. Это придает гибкость приложению.
Все медиаторы, будто главный или последний, должны регистрироваться в команде.
Прокси могут только оповещать, отправлять события но не принимать. Полностью изолированный класс от всей системы.
В команду можно прописать сколько угодно прокси и медиаторов, зависимо от логики приложения, архитектуры.

В итоге я пришел к тому, что PureMVC действительно очень прост в изучении, логичен и очень гибкий инструмент. Прошло 5 дней и он как на ладони) Осталось только начать и творить по принципу Пюре.

[Vasyaga]

Слегка касался PureMVC и видел некоторые примеры, где медиатор инициализируется при создании представления прямо в коде представления. Как я понимаю, это не есть здорово?

[Котяра]

PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?

[Dukobpa3]

Сообщение от alatar

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

Абсолютно не согласен, ибо считаю что один медиатор вполне способен обслуживать несколько однотипных видов. И именно в этом для меня и есть преимущество наличия такого класса как медиатор. Иначе он бесполезная прослойка.

Сообщение от alatar

Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.

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

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

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

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

[Vasyaga]

Сообщение от Dukobpa3

Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам.

Совершенно верно!

Сообщение от Dukobpa3

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

Прокси по логике PureMVC действительно регистрируются один раз и живут сколько нужно, чаще всего всю жизнь приложения, т.к. они являются частичным отражением модели. Команды там вообще существуют только во время их (команд) выполнения, потом экземпляр удаляется. А вот медиаторы, могут добавляться/удаляться произвольное количество раз. Пример: Мультидокументный редактор - на каждое представление (вид) документа - свой медиатор. Закрыл документ - уничтожилось представление и его медиатор.

Сообщение от Dukobpa3

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

Можно посылать нотификации и просто через синглтон фасада. Сам так делал. Не часто, но были случаи.

Сообщение от Dukobpa3

А дерево медиаторов это имхо просто опа неподдерживаемая.

Абсолютно не согласен. Пюре же дает механизм нотификаций, т.е. мы избавлены от привязки к стандартной модели событий и их баблингу: кто подписался на сообщение, тот его и будет обрабатывать. И совсем не обязательно элементом дерева медиаторов знать друг о друге: уничтожил вью, уничтожил медиатор. Или вы о чем-то другом?

Добавлено через 10 минут

Сообщение от Котяра

PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?

А если почитать тему про Хорошее MVC, то мнения многих людей там противоречат друг другу. Вью/контроллеры выделяются в отдельную группу, а модель содержит в себе и бизнес-логику, и получение и хранение данных, что как-бы намекает на разделение, подобное PureMVC. Плюс нотификации пюре решают проблему коммуникаций между частями приложения. Я, конечно, понимаю, что и у пюре есть свои проблемы, но он спокойно работает и позволяет разрешить некоторые неоднозначности классического MVC.

[Dukobpa3]

Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три:
m -> v
v -> c
c -> c

Было бы более кошерное мвц, которое можно и с такой архитектурой фреймворка организовать, но всё-таки лучше если еще и технически как-то ограничено.

[alatar]

Сообщение от Dukobpa3

Абсолютно не согласен, ибо считаю что один медиатор вполне способен обслуживать несколько однотипных видов. И именно в этом для меня и есть преимущество наличия такого класса как медиатор. Иначе он бесполезная прослойка.

Мне надо было как-то выделить "экземпляр"?

Сообщение от Dukobpa3

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

Опять же, почему бы не дочитать предложение до конца и при чем тут регистрация/дерегистрация? Речь о ЭКЗЕМПЛЯРАХ.[/quote]

Добавлено через 2 минуты

Сообщение от Dukobpa3

Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три...

Было бы лучше вообще без обсервера, в той реализации в которой он есть.

[Dukobpa3]

Мне надо было как-то выделить "экземпляр"?

Пюре весь на синглтонах. Вот как раз пересоздание екземпляров мне и не понравилось.
Вью-обжекты пусть создаются пересоздаются и умирают. А с медиаторами этого делать не обязательно. Хотя есть примеры, вон как с редактором мультиоконным, где это оправданно. В массе же своей - нет.

при чем тут регистрация/дерегистрация?

Екземпляр медиатора не зарегистрированный в фасаде - смысла не имеет. Именно это я и имел в виду. И даже если сам екземпляр медиатора не убивается, а только регистрируется/дерегистрируется - то суть та же. Для системы он умирает.
Поэтому для меня в этом контексте регистрация медиатора == его пересоздание. А будет это новый екземпляр или тот который где-то в пуле пролежал - не суть важно.