PureMVC Медиаторы
Начал учить PureMVC и походу возникли некоторые вопросы.
Правильно ли пихать все Медиаторы в главный Медиатор приложения, регистрируя их и оповещать все вместе? Если будут компоненты 20-30 шт. скажем, разумно ли все это обрабатывать в одном классе? Что то мне трудно дается отношение между Медиатором и всей системы( |
Медиатор служит прослойкой между его видом и приложением. Он знает какие события генерирует вид, как преобразовать их для приложения и как оповестить приложение о событии, а также получает ссылку на модель для своего вида. Для однотипных видов, медиаторы могут быть также однотипны. Но, в любом случае, для каждого экземпляра вида, создается отдельный экземпляр соответствующего ему медиатора.
|
Я это знаю)
Вопрос был - правильно ли разместить (регистрировать) все другие медиаторы в один главный Медиатор? То есть управлять только через главный Медиатор. Примерно так: Код AS1/AS2:
|
Нет неправильно. Даже если закрыть глаза, на то что так (new IndexPage().show о_О) регистрировать медиаторы даже по меркам pureMVC неправильно.
|
А как по вашему должно быть правильно? Пожалуйста дайте мне хоть какой то совет, я уже голову переломал над этой архитектурой.
На данный момент мой код делает одно, все компоненты обрабатывает свой медиатор, главный медиатор получает ссылки на все остальные медиаторы и слушает события от всех. С главного медиатора я могу воздействовать на публичные свойства, методы других медиаторов. Мне этот вариант показался удобным. |
Я давно уже не работал с pureMVC, однако открыв свои старые исходники я обнаружил, что я так и делал, регистрировал медиатры в главном. Насколько я помню, в документации, тьюториалах, и тех примерах приложений на pureMVC, которые мне удалось найти в инете, так и делалось, поэтому мне интересно послушать, почему это неправильно :-) Еще попадался вариант где медиатры регистрировались в командах, но не знаю лучше это или нет. И да, pureMVC здесь не любят, поэтому ожидаю советы типа "вообще не следует работать с этим г..м", но надеюсь что хоть что то по существу будет сказано).
|
PainKiller, ожидаемые ответы у вас правильные, pureMVC на редкость корявое решение в рамках as3 и flash platform. Я тоже уже не работал с ним лет пять.
По существу. Если вы заметили, то в этих примерах в медиаторе главного вида регистрируются медиаторы для видов, которые являются частями главного вида и уже находятся в списке отображения. Такой подход накладывает некоторые ограничения на переконфигурирование приложения, вам уже недостаточно поменять контроллер (команды инициализации главного вида и добавления новых видов в список отображения), но придется еще и править медиаторы. Увы, я не нашел официального примера с приложением в котором виды создавались бы не все сразу при старте приложения. Цитата:
Цитата:
namespaces, суть MVC-фреймворков повысить гибкость и удобство изменения приложения во время его эволюции и роста. Это достигается, в частности, тем что части приложения независимы и ничего не знают о других частях (за исключением контроллеров). |
Цитата:
Я так понял вы имеете ввиду, не инициализировать все медиаторы одновременно без надобности или на каждый медиатор повесить свою команду (контроллер)? Цитата:
|
Нет вида на экране == нет медиатора. Команда, по событию, создает и добавляет вид на экран и регистрирует его медиатор и удаляет предыдущий вид и его медиатор, если в них уже нетнадобности.
|
alatar, спасибо за ответ.
Цитата:
|
Цитата:
Цитата:
Добавлено через 2 минуты Может я действительно что то не дочитал, не понял до конца всю концепцию MVC. |
Цитата:
|
Цитата:
Код AS3:
К тому же, при удалении спрайта из Медиатора, сам компонент все еще висит в памяти. Если удалить таким образом Код AS3:
Ах да! По моему начинаю понимать что к чему. На каждую вьюшку (компонент) создаю свой медиатор, то есть даже одна кнопочка сама по себе не может участвовать в фреймворке без посредника - медиатора. Это прежде всего полезно тем, что мы можем в будущем менять кнопки (классы) как хотим, без затрагивания всего кода и инициализация пройдет автоматически с заранее подготовленным медиатором. И что самое интересное, штатные оповещения (dispatchEvent) используются только внутри вьюшек (компонентов) и нигде больше. Это придает гибкость приложению. Все медиаторы, будто главный или последний, должны регистрироваться в команде. Прокси могут только оповещать, отправлять события но не принимать. Полностью изолированный класс от всей системы. В команду можно прописать сколько угодно прокси и медиаторов, зависимо от логики приложения, архитектуры. В итоге я пришел к тому, что PureMVC действительно очень прост в изучении, логичен и очень гибкий инструмент. Прошло 5 дней и он как на ладони) Осталось только начать и творить по принципу Пюре. |
Слегка касался PureMVC и видел некоторые примеры, где медиатор инициализируется при создании представления прямо в коде представления. Как я понимаю, это не есть здорово?
|
PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?
|
Цитата:
Цитата:
Есть к примеру медиатор попапов. То что зарегистрировалось в фасаде пусть там и висит, есть не просит. (в угоду производительности конечно можно разные варианты применять, но регистрация/дерегистрация медиаторов, команд, прокси в пюре - часто тупой оверхед ненужный). А вот сами виды - да, можно прятать, дестроить, что угодно с ними делать. Но опять же. Без предыдущего утверждения - этот момент будет не всегда оправдан. Т.е. если медиатор == вью-обжект - тогда как бы придется регистрировать или убирать. Но ЗАЧЕМ???? //****************** Итого: Команда - одна команда ОДНО действие с ОДНИМ уровнем абстракции, с ОДНИМ срезом логики. Пишет данные в прокси. Слушает нотификации кликов и прочей мути из медиаторов. Прокси - один прокси умеет работать с НЕСКОЛЬКИМИ дата-обжектами. Через паблик методы принимает данные от команд. Шлет нотификации медиаторам. Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам. Медиаторы, прокси, команды - зарегистрировал один раз и пусть живут. Если есть необходимость их убирать из фасада - скорее всего архитектура косая. (Я не беру в учет супер круто написанный проект в котором везде вместо i++ - стоит ++i и прочая муть, и все-равно для оптимизации производителоьности вот прямо ппц как необходимо это сделать). Если не для производительности а по логике - нафиг такую логику. Добавлено через 7 минут И еще один момент меня колбасит ппц как. То что вы юзаете пюре абсолютно не значит что ВСЁ должно быть наследниками классов пюре. Регистрацию команд или медиаторов проще вынести в отдельный какой-то менеджер. А дерево медиаторов это имхо просто опа неподдерживаемая. |
Цитата:
Цитата:
Цитата:
Цитата:
Добавлено через 10 минут Цитата:
|
Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три:
m -> v v -> c c -> c Было бы более кошерное мвц, которое можно и с такой архитектурой фреймворка организовать, но всё-таки лучше если еще и технически как-то ограничено. |
Цитата:
Цитата:
Добавлено через 2 минуты Цитата:
|
Цитата:
Вью-обжекты пусть создаются пересоздаются и умирают. А с медиаторами этого делать не обязательно. Хотя есть примеры, вон как с редактором мультиоконным, где это оправданно. В массе же своей - нет. Цитата:
Поэтому для меня в этом контексте регистрация медиатора == его пересоздание. А будет это новый екземпляр или тот который где-то в пуле пролежал - не суть важно. |
Значит я уже подзабыл насколько в pureMVC все печально, четыре года на нем ничего не делал.
P.S. Пересмотрел код, ничего и не поменялось за это время. |
так а что там менять.
восемь классов. всё публично, всё динамично. Крути какое хочь г-но. Никаких ограничений. Фейспалм, короче. Непонятно почему он так любим в ентерпрайзах всяких. |
Вот как раз в энтерпрайзах я лично его не встречал. Но скорее всего просто не попадалось.
|
В энтерпрайзах парсли и мате. Очень древнее на пюре и конгхорме иногда встречается.
|
Parsley мне лично не понравился, безалаберный он какой-то, хотя интересные веши в нем есть. С Mate не довелось столкнуться. Пока в моем рейтинге рулит robotlegs.
|
Часовой пояс GMT +4, время: 06:39. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.