|
|
|||||
Banned
[+1 06.12.14]
[+1 18.12.14] [+1 30.12.14] Регистрация: Aug 2014
Сообщений: 461
|
Цитата:
Но я как малоопытный возьму на себя все тяжкую ношу ответа, а уж пусть опытные меня критикуют, так будет легче диалог наладить))) Во первых - есть много всяких mvc и это не только чьё-то личное предпочтение, это уже от вида приложения зависит. Если Вы делаете чисто akti приложение, то это одно mvc - назовем его нубское, так как все фигуранты помещены во вью, чем и является flash по своей сути. Лично я при такой схеме делаю главную вью, главную модель и главный контроллер. И вот главная модель, где заключена логика приложения, диспатчит событие, что нужно переключить вью одной локации на другую. Главная вью лезет в модель и берет ссылку на модель и передает её во вью-чилд при создании. И так далее. А второй вариант, это когда flash это вью, модель сервер... И тут уже не работает стандартная модель, так как появляются медиаторы и маленькие контроллеры, а модели ( не серверная ) собираются на лету в специальном месте и передаются там же во вью взятым из фабрик. И все это делается по заранее написанным конфигам и так далее... |
|
|||||
[+1 25.10.13]
[+4 18.03.14] |
Продумайте и постройте сначала архитектуру приложения, а уже потом пишите код. Я обычно проектирую записывая ее в виде XML файла, но JSON лучше при реализации. Затем Вы траверсите JSON, связывайте ноды моделей с классами вью или контроллеров, в контроллерах происходит коммуникация между отдельными компонентами MVC, посредством передачи своей ноды данных . Разумно сразу продумывать всё на парадигме интерфейсов и фабрик. Это минимизирует структуру и сам код. Используйте общий объект глобально доступный для всех частей вашего MVC, что-то типа $scope в AngularJS.
|
|
|||||
небольшой оффтоп. С утра, перечитав, понял, что обязан извиниться за опечатки )
__________________
http://cleptoman.free-lance.ru achivements: дважды благословлен на воровство. осеяный благодатью |
|
|||||
[+4 06.05.14]
|
Цитата:
__________________
Марк Tween |
|
|||||
Регистрация: Nov 2001
Адрес: Казань
Сообщений: 118
|
Тема жевана-пережевана. svdsLis, вы можете сделать как вам нравиться, но эмпирическим путём доказано, что в большинстве случаев, вьюшке удобнее слушать изменения модели. Представьте, что вам нужно отображать некую величину в текстовом, индикаторном (например, линейка здоровья) и графическом (вид зависит от значения величины) виде? Вместо того, чтобы контроллеру вызывать цепочки методов дочерних контроллеров, каждому виду лучше подписаться на события модели и обновляться.
1 - лучше сделать бабл. Бабл - удобно. 2 - пишите свои события. Если ваша модель имеет много изменяемых свойств, то удобнее диспатчить изменения отдельного свойства. |
|
|||||
[+1 25.10.13]
[+4 18.03.14] |
Cybo, может тема и пережевана, но каждым по-своему. Поэтому имеет смысл прожевать ещё.
Цитата:
|
|
|||||
Banned
[+1 06.12.14]
[+1 18.12.14] [+1 30.12.14] Регистрация: Aug 2014
Сообщений: 461
|
Babylon++
Цитата:
Добавлено через 56 секунд Цитата:
|
|
|||||
__________________
http://cleptoman.free-lance.ru achivements: дважды благословлен на воровство. осеяный благодатью |
|
|||||
[+1 25.10.13]
[+4 18.03.14] |
Какие у модели события?
|
|
|||||
Lorem ipsum
|
Цитата:
Или: И это очень даже удобно. Другое дело, что мастерить "всплывание" тупо лень (каюсь, я сам до этого так и не дошел, подписываю вьюхи и контроллеры непосредственно на нужные им модели). По месту смотреть надо. Порой и вовсе без событий можно (нужно) обойтись. Ну, например, если у тебя в разных местах логики меняются, скажем, x, y и state. Если это, например, моделька юнита в игре про атаку клонов ) то тулить каждой вьюхе каждого отдельного юнита ТРИ события, которые меняют ее отображение ТРИ раза целиком (если это просто CHANGE, мы же не знаем, что поменялось) или по частям (если заморочиться и накатать таки CHANGE_X, CHANGE_Y, CHANGE_STATE), это не есть хорошо. Тут лучше и вовсе обойтись без событий. Достаточно просто каждой вьюхе отдельного юнита по своему ентерфрейму, или даже из одного родительского ентерфрейма в цикле вызывая метод redraw или update (или как там еще) у каждого юнита, перерисоваться ОДИН раз. Если нужно, можно даже инвалидаторы (так вроде называются) притулить в модель. Это такие булевы переменные, которые указывают, поменялось ли что-то с тех пор, как последний раз интересовались. Ну это если таки да нужно не делать холостых ходов. Например не годится постоянно менять отображение юнита на то же самое (это порой сопряжено с add/removeChild или переключением видимости и все такое).
__________________
Поймай яблоко 2! |
Часовой пояс GMT +4, время: 06:28. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|