Вопрос про MVC
 

Всем здравствуйте. Сейчас изучаю MVC шаблон (парадигму) и столкнулся с некоторым не понимаем.

Вопрос №1: Допустим в главной модели (GlobalModel) есть ещё 2 (CharacterModel, LocationModel). И изменилась одна из под-моделей. Как правильно осуществить диспетчеризацию?
- в каждую под-модель передавать GlobalModel и из неё вызывать диспетчерезацию?
- или делать bubble (но это не удобно)

Вопрос №2: Как правильно диспетчирезировать события изменения модели?
- использовать только одно событие "Event.CHANGE" или создавать для этого свои классы событий

Если не используете специализированных фреймворков:
1) Как вам удобнее. Разве не контроллер должен дергать вьюхи, рассказывая, что изменилась моделька? Модель же изменяется контроллером?
2) Как вам удобнее.

У меня индикатор здоровья робота, выраженный во вью, как ряд из трех лампочек, от зеленого к красному с желтым в середине. Модель создана только посылать событие, что одна жизнь исчерпана. Вопрос - как контроллер узнает какую лампочку ему включить?

Добавлено через 2 минуты
Хотя я наверно не правильно понял Ваши слова. Когда я прочел Ваши слова, то в голове нарисовалась картинка из слов сказанных не Вами, но гласящих, что контроллер включает нужную вью.

Добавлено через 2 минуты
Вы случаем не об этом?)

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

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

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

Правильно ли я понимаю, что код вроде этого, должен находиться в модели:
А в контроле должно быть:
Тобишь контролер должен/может заставить модель само измениться?

С Вами я согласен, мне просто очень интересно мнение GBee, если же он конечно придерживается концепции, где контроллер решает, какую вью нужно включать. В последнее время я все чаще слышу о том, что контроллер должен выбирать вид...

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

это как на картинках...в жизни все может быть несколько сложней

Только вот спрашиваю я про другое.

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

Вот неэтично задавать такие провокационные вопросы профессионалам:)
Но я как малоопытный возьму на себя все тяжкую ношу ответа, а уж пусть опытные меня критикуют,
так будет легче диалог наладить)))
Во первых - есть много всяких mvc и это не только чьё-то личное предпочтение, это уже от вида приложения зависит.
Если Вы делаете чисто akti приложение, то это одно mvc - назовем его нубское, так как все фигуранты помещены во вью, чем и является flash по своей сути. Лично я при такой схеме делаю главную вью, главную модель и главный контроллер. И вот главная модель, где заключена логика приложения, диспатчит событие, что нужно переключить вью одной локации на другую. Главная вью лезет в модель и берет ссылку на модель и передает её во вью-чилд при создании. И так далее.
А второй вариант, это когда flash это вью, модель сервер... И тут уже не работает стандартная модель, так как появляются медиаторы и маленькие контроллеры, а модели ( не серверная ) собираются на лету в специальном месте и передаются там же во вью взятым из фабрик. И все это делается по заранее написанным конфигам и так далее...

Продумайте и постройте сначала архитектуру приложения, а уже потом пишите код. Я обычно проектирую записывая ее в виде XML файла, но JSON лучше при реализации. Затем Вы траверсите JSON, связывайте ноды моделей с классами вью или контроллеров, в контроллерах происходит коммуникация между отдельными компонентами MVC, посредством передачи своей ноды данных . Разумно сразу продумывать всё на парадигме интерфейсов и фабрик. Это минимизирует структуру и сам код. Используйте общий объект глобально доступный для всех частей вашего MVC, что-то типа $scope в AngularJS.

небольшой оффтоп. С утра, перечитав, понял, что обязан извиниться за опечатки )

Какой в этом плюс ? Если у нас 3-4 вью, - да. А если их много? И половине из них нужны разные модели и т.п. Тоесть архитектура не совсем уж маленькая?! BaseModel - обязан быть. А будешь ли ты его пихать на все случаи жизни, или же держать каждый отдельно - дело ваше. Но тут палка о двух концах, и тут как раз моя любимая *как два программиста хлеб пекли* - может получится.

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

1 - лучше сделать бабл. Бабл - удобно.
2 - пишите свои события. Если ваша модель имеет много изменяемых свойств, то удобнее диспатчить изменения отдельного свойства.

Cybo, может тема и пережевана, но каждым по-своему. Поэтому имеет смысл прожевать ещё.
- сильно сказано. Свежо, ноне правильно.

Babylon++
Стоит только добавить, что у НЕ ДО баблинга нет и врятли его делать стоит.

Добавлено через 56 секунд
Она всегда на этом месте останавливается.

а что тут не так?

Какие у модели события?

Нет. Каждая модель сама посылает свои события. Все кому нужно, могут слушать эти события, подписавшись на них непосредственно в этой конкретной модели.
Или:
И это очень даже удобно. Другое дело, что мастерить "всплывание" тупо лень (каюсь, я сам до этого так и не дошел, подписываю вьюхи и контроллеры непосредственно на нужные им модели).

По месту смотреть надо. Порой и вовсе без событий можно (нужно) обойтись. Ну, например, если у тебя в разных местах логики меняются, скажем, x, y и state. Если это, например, моделька юнита в игре про атаку клонов ) то тулить каждой вьюхе каждого отдельного юнита ТРИ события, которые меняют ее отображение ТРИ раза целиком (если это просто CHANGE, мы же не знаем, что поменялось) или по частям (если заморочиться и накатать таки CHANGE_X, CHANGE_Y, CHANGE_STATE), это не есть хорошо. Тут лучше и вовсе обойтись без событий. Достаточно просто каждой вьюхе отдельного юнита по своему ентерфрейму, или даже из одного родительского ентерфрейма в цикле вызывая метод redraw или update (или как там еще) у каждого юнита, перерисоваться ОДИН раз. Если нужно, можно даже инвалидаторы (так вроде называются) притулить в модель. Это такие булевы переменные, которые указывают, поменялось ли что-то с тех пор, как последний раз интересовались. Ну это если таки да нужно не делать холостых ходов. Например не годится постоянно менять отображение юнита на то же самое (это порой сопряжено с add/removeChild или переключением видимости и все такое).

Самые обыкновенные, об изменении себя. Их слушает вьюшка и меняется.

Если модель меняется в контроллере, то по завершении изменения значения модели вьюшке передается измененное значение. Событие об изменении значения модели посылает обработчик из контроллера виду и вид меняется. А если модель подписана на события вьюшки, а вьюшка на события модели, то и контроллер не нужен.

Babylon, классическую картинку про устройство MVC вообще никогда не видел что ли?

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

Неча на модель пенять, коли руки кривы :)))

Лучше даже не говорить так: контроллер меняет модель. Строго говоря, модель — логическое ядро приложения, оно само там кипит/бурлит/меняется, о чем мы, как все уже понимают, узнаем из посылаемых событий и из всяких геттеров. Контроллер же просто дергает предоставленные моделью методы, через которые модель таким образом узнает, что там происходит в мире: може кто кнопочку "стрелять" нажал, или данные откуда-то с сервера прилетели, и т.д.

вот еще один кандидат в еретики )

Babylon, да, Вы все напутали. Контроллер вправе менять вью и модель напрямую. Вью меняется от событий модели. Вью сообщает событиями контроллеру о своих интерактивностях.

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

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

Добавлено через 1 минуту
КорДум, я про это же и говорю.

Babylon, Вы говорите о том же, но только продвигаете самый не рекомендуемый вариант.
Который наверняка переняли из js.

естественно, чтобы вьюхи ловили события МОДЕЛИ в них должны быть хендлеры событий МОДЕЛИ.

Gerbert, что плохого в коммандере, находящимся в контроллере, событийно управлющим вьюшкой?

А зачем тогда модель? Даже описание с вики, которое гласит, что подход с пассивной моделью плох из-за того,
что web разработчики используют БД, как хранилище и БД === модель... Это полная фигня, так как я не понимаю,
какое отношение хранилище имеет к модели. При жирном контроллере модель вообще не нужна, но это и не говорит,
что в классическом варианте нет нужды в контролере. Хоть гоф и опустил в своих толкованиях контроллер ( чем запустил развитие паранойи у большинства программистов ), он все же очень нужен и его обязанности нельзя разделить между видом и моделью. В варианте с тонким контроллером царит наибольшая эдилия с точки зрения ООП. Это мне так кажется.

Добавлено через 52 секунды
Или Вы говорите о сервисах, которые выполняются в контроллере?

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

Babylon, да понимаю о чем Вы, но во flash наверное об этом боятся говорить и это и является, как Вы уже заметили, неохотно и мало обсужденным. В js нет модели, в angular нет моделей, там есть только вид и все с ним связанное, но для простаты ( или из-за скудной фантазии ) там есть вью-моделm, которые называются модель? хотя модель это сервер и в js её существование невозможно.
В клиент-серверном приложении flash же тоже только представление и в таком контексте его можно сравнивать с js,
но когда говорят о mvc, то говорят о настольной версии, где flash-представление представляется полноценным mvc подгруппами.

Изучая TypeScript я пришел к простому выводу, что классы нужны в основном для создания интерфейсов. Всё остальное это объект и его schema.

эка вы типизацию витиевато обозвали.

Скорее так: логика, не вынесенная из модели. Прямо какая-то невыносимая логика!

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

В моем понятии, моделью называют то, что содержит логику приложения и находится на сервере.
Js к серверу отношения не имеет ( nodejs не в счет ) и является представлением. И вот у меня мысли
разбегаются, когда говорят, что в js есть модель... Сервер засунули в представление.. Как?