Форум Flasher.ru - [PureMVC] PureMVC Медиаторы

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- API приложений и сред (http://www.flasher.ru/forum/forumdisplay.php?f=61)

- -

PureMVC Медиаторы (http://www.flasher.ru/forum/showthread.php?t=202894)

Цитата:

Сообщение от alatar (Сообщение 1144239)

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

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

Цитата:

Сообщение от PainKiller (Сообщение 1144248)

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

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

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

Цитата:

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

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

Цитата:

Сообщение от PainKiller (Сообщение 1144344)

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

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

Код AS3:

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 сообщениями, по моему что то не так(
К тому же, при удалении спрайта из Медиатора, сам компонент все еще висит в памяти.
Если удалить таким образом

Код AS3:

viewComponent.removeChild(window);

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

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

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

Цитата:

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

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

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

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150406)

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

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

Цитата:

Сообщение от Dukobpa3 (Сообщение 1150437)

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

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

Цитата:

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

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

Цитата:

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

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