Форум 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)

namespaces

17.08.2013 20:23

PureMVC Медиаторы

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

alatar

18.08.2013 11:55

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

namespaces

18.08.2013 23:25

Я это знаю)
Вопрос был - правильно ли разместить (регистрировать) все другие медиаторы в один главный Медиатор?
То есть управлять только через главный Медиатор.
Примерно так:

Код AS1/AS2:

public function MainMediator()

                {

                        super(NAME);

 

                        facade.registerMediator( new IndexPage().show);

                        facade.registerMediator( new HomePage().show);

                        facade.registerMediator( new NavPage().show);

                        facade.registerMediator( new AboutPage().hide);

                        facade.registerMediator( new ServicePage().hide);

                        facade.registerMediator( new PortfolioPage().hide);

                        facade.registerMediator( new ContactPage().hide);

                }

alatar

19.08.2013 00:12

Нет неправильно. Даже если закрыть глаза, на то что так (new IndexPage().show о_О) регистрировать медиаторы даже по меркам pureMVC неправильно.

namespaces

19.08.2013 01:09

А как по вашему должно быть правильно? Пожалуйста дайте мне хоть какой то совет, я уже голову переломал над этой архитектурой.
На данный момент мой код делает одно, все компоненты обрабатывает свой медиатор, главный медиатор получает ссылки на все остальные медиаторы и слушает события от всех.
С главного медиатора я могу воздействовать на публичные свойства, методы других медиаторов. Мне этот вариант показался удобным.

PainKiller

19.08.2013 17:01

Я давно уже не работал с pureMVC, однако открыв свои старые исходники я обнаружил, что я так и делал, регистрировал медиатры в главном. Насколько я помню, в документации, тьюториалах, и тех примерах приложений на pureMVC, которые мне удалось найти в инете, так и делалось, поэтому мне интересно послушать, почему это неправильно :-) Еще попадался вариант где медиатры регистрировались в командах, но не знаю лучше это или нет. И да, pureMVC здесь не любят, поэтому ожидаю советы типа "вообще не следует работать с этим г..м", но надеюсь что хоть что то по существу будет сказано).

alatar

19.08.2013 21:45

PainKiller, ожидаемые ответы у вас правильные, pureMVC на редкость корявое решение в рамках as3 и flash platform. Я тоже уже не работал с ним лет пять.

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

Увы, я не нашел официального примера с приложением в котором виды создавались бы не все сразу при старте приложения.

Цитата:

А как по вашему должно быть правильно?

У вас медиаторы создают виды?

Цитата:

С главного медиатора я могу воздействовать на публичные свойства, методы других медиаторов.

Зачем им вообще дополнительные публичные свойства? Для взаимодействования частей приложения в pureMVC есть уведомления (notifications). Медиаторы вообще не должны знать о других медиаторах.

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

namespaces

20.08.2013 00:47

Цитата:

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

У вас медиаторы создают виды?

Неа. Медиаторы играют роль посредника между компонентом и контроллером.
Я так понял вы имеете ввиду, не инициализировать все медиаторы одновременно без надобности или на каждый медиатор повесить свою команду (контроллер)?

Цитата:

Да вы правы. Я иногда вообще забываю про внутреннее уведомление фреймворка и посылаю-получаю штатным способом.

alatar

20.08.2013 02:32

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

PainKiller

20.08.2013 10:33

alatar, спасибо за ответ.

Цитата:

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

namespaces

21.08.2013 02:47

Цитата:

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

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

Цитата:

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

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

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

PainKiller

21.08.2013 11:05

Цитата:

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

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

namespaces

22.08.2013 01:28

Цитата:

Сообщение от 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 дней и он как на ладони) Осталось только начать и творить по принципу Пюре.

Vasyaga

29.10.2013 20:29

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

Котяра

30.10.2013 00:19

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

Dukobpa3

30.10.2013 01:00

Цитата:

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

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

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

Цитата:

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

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

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

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

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

Vasyaga

30.10.2013 07:08

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Dukobpa3

30.10.2013 12:25

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

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

alatar

30.10.2013 13:37

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Dukobpa3

30.10.2013 14:15

Цитата:

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

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

Цитата:

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

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

alatar

30.10.2013 15:58

Значит я уже подзабыл насколько в pureMVC все печально, четыре года на нем ничего не делал.
P.S. Пересмотрел код, ничего и не поменялось за это время.

Dukobpa3

30.10.2013 16:01

так а что там менять.
восемь классов.
всё публично, всё динамично. Крути какое хочь г-но. Никаких ограничений.
Фейспалм, короче.
Непонятно почему он так любим в ентерпрайзах всяких.

alatar

30.10.2013 16:57

Вот как раз в энтерпрайзах я лично его не встречал. Но скорее всего просто не попадалось.

Котяра

30.10.2013 22:53

В энтерпрайзах парсли и мате. Очень древнее на пюре и конгхорме иногда встречается.

alatar

31.10.2013 02:29

Parsley мне лично не понравился, безалаберный он какой-то, хотя интересные веши в нем есть. С Mate не довелось столкнуться. Пока в моем рейтинге рулит robotlegs.

Часовой пояс GMT +4, время: 06:39.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.