Цитата:
Цитата:
Добавлено через 2 минуты Может я действительно что то не дочитал, не понял до конца всю концепцию MVC. |
Цитата:
|
Цитата:
Код AS3:
К тому же, при удалении спрайта из Медиатора, сам компонент все еще висит в памяти. Если удалить таким образом Код AS3:
Ах да! По моему начинаю понимать что к чему. На каждую вьюшку (компонент) создаю свой медиатор, то есть даже одна кнопочка сама по себе не может участвовать в фреймворке без посредника - медиатора. Это прежде всего полезно тем, что мы можем в будущем менять кнопки (классы) как хотим, без затрагивания всего кода и инициализация пройдет автоматически с заранее подготовленным медиатором. И что самое интересное, штатные оповещения (dispatchEvent) используются только внутри вьюшек (компонентов) и нигде больше. Это придает гибкость приложению. Все медиаторы, будто главный или последний, должны регистрироваться в команде. Прокси могут только оповещать, отправлять события но не принимать. Полностью изолированный класс от всей системы. В команду можно прописать сколько угодно прокси и медиаторов, зависимо от логики приложения, архитектуры. В итоге я пришел к тому, что PureMVC действительно очень прост в изучении, логичен и очень гибкий инструмент. Прошло 5 дней и он как на ладони) Осталось только начать и творить по принципу Пюре. |
Слегка касался PureMVC и видел некоторые примеры, где медиатор инициализируется при создании представления прямо в коде представления. Как я понимаю, это не есть здорово?
|
PureMVC и здорово не пишутся в одном предложении. Может оно вообще вам не надо?
|
Цитата:
Цитата:
Есть к примеру медиатор попапов. То что зарегистрировалось в фасаде пусть там и висит, есть не просит. (в угоду производительности конечно можно разные варианты применять, но регистрация/дерегистрация медиаторов, команд, прокси в пюре - часто тупой оверхед ненужный). А вот сами виды - да, можно прятать, дестроить, что угодно с ними делать. Но опять же. Без предыдущего утверждения - этот момент будет не всегда оправдан. Т.е. если медиатор == вью-обжект - тогда как бы придется регистрировать или убирать. Но ЗАЧЕМ???? //****************** Итого: Команда - одна команда ОДНО действие с ОДНИМ уровнем абстракции, с ОДНИМ срезом логики. Пишет данные в прокси. Слушает нотификации кликов и прочей мути из медиаторов. Прокси - один прокси умеет работать с НЕСКОЛЬКИМИ дата-обжектами. Через паблик методы принимает данные от команд. Шлет нотификации медиаторам. Медиатор - один медиатор умеет работать с НЕСКОЛЬКИМИ вью-обжектами. Слушает нотификации из прокси. Шлет нотификации командам. Медиаторы, прокси, команды - зарегистрировал один раз и пусть живут. Если есть необходимость их убирать из фасада - скорее всего архитектура косая. (Я не беру в учет супер круто написанный проект в котором везде вместо i++ - стоит ++i и прочая муть, и все-равно для оптимизации производителоьности вот прямо ппц как необходимо это сделать). Если не для производительности а по логике - нафиг такую логику. Добавлено через 7 минут И еще один момент меня колбасит ппц как. То что вы юзаете пюре абсолютно не значит что ВСЁ должно быть наследниками классов пюре. Регистрацию команд или медиаторов проще вынести в отдельный какой-то менеджер. А дерево медиаторов это имхо просто опа неподдерживаемая. |
Цитата:
Цитата:
Цитата:
Цитата:
Добавлено через 10 минут Цитата:
|
Я думаю пюре было бы приятнее если бы в нем был не один обсервер а три:
m -> v v -> c c -> c Было бы более кошерное мвц, которое можно и с такой архитектурой фреймворка организовать, но всё-таки лучше если еще и технически как-то ограничено. |
Цитата:
Цитата:
Добавлено через 2 минуты Цитата:
|
Цитата:
Вью-обжекты пусть создаются пересоздаются и умирают. А с медиаторами этого делать не обязательно. Хотя есть примеры, вон как с редактором мультиоконным, где это оправданно. В массе же своей - нет. Цитата:
Поэтому для меня в этом контексте регистрация медиатора == его пересоздание. А будет это новый екземпляр или тот который где-то в пуле пролежал - не суть важно. |
Часовой пояс GMT +4, время: 00:52. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.