Хорошее MVC

[dimarik]

Мои рассуждения о доставке в нужный контроллер.

Можно распространять события по цепочке - chain of responsibility. Причем цепочка легко превращается в дерево, если следовать паттерну визуальных объектов. Если в первом (основном) контроллере нашелся нужный метод, контроллер делает event.stopImmediatlyPropagation(). Иначе событие передается дальше, к дочернему контроллеру посредством бабблига. Если он может такое событие обработать, то можно сделать следующее: либо event.stopImmediatlyPropagation(), либо event.preventDefault(). Во втором случае в основном контроллере можно понять, что событие не нашло адресата, проверив результат выполнения метода super.dispatchEvent() и как-то отреагировать. false означает что событие было захвачено, true - подходящий адресат не был найден.

Другой вопрос, оправдано ли ветвление контроллеров.

[Psycho Tiger]

dimarik, мысль ясна, спасибо. Я так понимаю если 2 дочерних контроллера, то событие отправляется в каждый. Только непонятно, как реагировать, если в обеих дочерних оно дошло до адресата )

P.S. сейчас вот пишу казино. Там есть общие окна для всех режимов игры (сама игра, зритель, курилка, лобби и т.д.), типа посмотреть информацию об игроке, отправить подарок, открыть окно привата и т.д.
Оно всё взаимодействует с сервером, конечно, поэтому без контроллера не обойтись. В итоге я вынес мозги этих общих действий в базовый контроллер, базовая вьюшка всегда находится в DisplayList, она же является host`ом (display object container`ом) для всех остальных вьюшек. Если надо открыть окно - событие просто бабблится по вьюшкам, а возле главной вьюшки её ловит главный контроллер. Главный контроллер создаёт так же другие контроллеры (например, контроллер лобби), который уже размышляет о том, о чем ему сделать, а когда нужно отправить что-то на сервер - монопольно дёргает call и vkontakteCall у главного контроллера (ну, что описал Дениска, в принципе). По моему в таких случаях ветвление контроллеров не то что оправдано, а даже очень удобно. Интересно выслушать твоё мнение по поводу такой системы.

Добавлено через 28 часов 12 минут
P.S. dimarik, твой подход доставки в нужный контроллер чудо ) Не думал что на практике это будет столь удобно, спасибо огромное.

[3p.station]

сам только начал вникать в эту тему (жаль что еще нету задач котороые имело бы смысл так реалиозвать)
вот нашел
такой вариант описания с минимальным примером

и еще рекомендуют многие

роботлегс

[Psycho Tiger]

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

[3p.station]

если каждое приложение достаточно уникальное, то смысл тогда в MVC ?
если я верно понял, то этот паттерн для того чтобы эту уникальность и разрулить и например одну и туже модель исопльзовать не один раз и не в одном проекте, а следовательно она должна иметь какието "правила" котороые можно будет исопльзовать в дургом проекте и при этом не думать об переделвании интерфейсов и способов связывания между модулями
хотя это лишь мне так поудмалось

а вот по поводу той статьи что ниже я скинул, - вникнул и понял что там не то ):
там чел внизу про это и напаисал в комментах и дал ссылку на википедию

[Psycho Tiger]

Смысл MVC как раз в унифицированном решении проблемы архитектуры, когда требуется отделить данные от представления от манипуляции с этими данными. Ну вот проще говоря, не мыслю как паттерн можно под гребёнку смести, не говоря уж об архитектуре. Рассмотрим паттерн адаптер: он может служить единым интерфейсом для 2-3 социальных сетей, а может служить для единых входных данных от входных устройств - проще говоря управление мышкой/клавиатурой/джойстиком. Единственное что между ними общего - "единый интерфейс для работы с..." - но в этом и суть адаптера. Если смотреть со стороны MVC - общее это может быть некий абстрактный объект контроллера, модели и вьюхи, у которых расставлены эти связи между трио. Но эти связи во всех 3 классах дай бог нагребут 150-200 строчек кода. Я не вижу смысла ради 1% кода в проекте подстраивать под него остальные 99.
Описанное выше - конкретно моё имхо). Наверно, стоит пощупать эти фреймворки чтобы делать такие категоричные заявления... но как то не тянет.

[3p.station]

когда требуется отделить данные от представления от манипуляции с этими данными.

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

вообщем если честно, еще гулбоко не вникал в роботлегс , как чего пойму отпишусь ( :

[Psycho Tiger]

Не совсем. В идеале для меня так:
Вьюшка - отображает. Очень удобно тем, что невозможно отображением подпортить логику игры. Добавил вспышку света при взрыве гранаты - и никак не может произойти так, что из за вспышки у врага на крыше упали штаны. Такие баги допустить очень легко, когда всё в куче. Ещё удобно тем, что разработку можно вести на уровне кружочки-квадратики и не ощущать скованность из за неполноты представления - добавляя отображение мы меняем 33% кода, вместо всей 100 (если представить что модель-контроллер-вьюшка имеют равный объем кода, что почти всегда неверно ). Очень удобно когда ещё люди не знают, как будет выглядеть игра. Есть логика игры, а вот над представлением ещё думают, есть мелкий концепт. Чертовски удобно когда несколько видов игры - например вид сверху и вид сзади (3д, но игра функционала такого же как в 2д).

Модель - ну тут в идеале - полная информация о процессе. Идеальная модель для меня - это если удалить вьюшка и контроллер, а потом создать их снова чистенькие и отдать эту модель - всё восстановится в точности/почти в точности, как было раньше. Очень удобно для сериализации: если она не DisplayObject - то просто записываем в ByteArray - получаем AMF объект, который можем сохранить... да хоть в файл. Некоторые в качестве модели используют DisplayObject`ы, ради иерархии и бабблинга событий. Врать не буду - в целом идея удобная, а сериализовывать модели... ну лично мне не приходилось никогда. С другой стороны DisplayObject`ы едят больше памяти, чем просто EventDispatcher`ы, так что эти моменты весьма спорные. Но это я от темы отхожу.

Контроллер - ерунда которая всем этим делом управляет и содержит все мозги.

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

[cleptoman]

чуть не растерял остатки мозга, пока все страницы осилил.
понял одно: я не тру и отсталый недофлэшер)

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

раздает данные детям.
слушает детей на предмет запросов на обновления инфы.

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

понимаю как-то далековат я от MVC

[Psycho Tiger]

Понимание и прелести MVC приходит со временем. Поначалу начинаешь сам отделять управление от отображения, потом начинается разделение ещё и на данные, помимо отображения и управления, ну а потом осознание что визуализируются то данные, и по сути управление к отображению имеет мало отношения. И тут мы приходим к MVC..)