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

Так вот если это допустим текущая страница в магазине, скорее всего ее хранить нигде не надо, и можно листать страницы не сохраняя индекс страницы в модель. Ну и в таком духе.

Добавлено через 4 минуты
Так че тут обьяснять. Должно быть четкое разделение прав и обязанностей между контроллером моделью и вьюхой.

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

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

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

И вот чтоб вью слишком часто не рисовалась наша задача подумать как и что должна диспатчить модель и как часто.

Ну это мое видение мвц. С ним некоторые наверное не согласятся. А спорить я не хочу.

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

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

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

Ну это грубо. Вцелом то так и есть, но бывает по-разному.

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

Добавлено через 3 минуты
Нужно изначально понять саму идею разделения ролей на М В Ц. Тогда путаницы не будет.
Когда четко осознаешь обязанности каждого - половина вопросов сами отпадут.

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

Он имеет ссылку на вью, но это не значит что он может делать с ней всё что хочет. Ему ссылка нужна банально для того чтобы подписаться на события. В идеале этим нужно ограничиться.

Вот что пишет ПсихоТайгер
Вот цитата с твоего поста:
Что-то не сходится, если контроллер обрабатывает "нажатие клавиш" то как он "не может быть инициатором никакого действия"?

Я не считаю что тигер был прав.
Он в этих суждениях допускает стандартную ошибку всех начинающих работать по мвц - думает что контроллер всему голова, а модель - тупо набор данных.
Это не так. Логика в модели. А контроллер может ей сказать: Ану-ка подруга, обнови-ка свои данные об вот этом вот контакте. И она обновит, а вьюшка увидит и нарисует этот контакт.

Но не так что контроллер говорит: модель, вот этот контакт заблокировать, поставить ему аватару вот такую, и поставить ему друзей вот таких вот. Модель сама знает откуда информацию черпать. Контроллер манагерит чисто на уровне команд.

Жесть, да там всю статью об этом говориться, что контроллер всему голова и etc это подтверждает, а тут вдруг оказывается... Где истина?
Контроллер что и клавиши не слушает? Чем он вообще будет заниматься если приложение не серверное?

in vino veritas

Я таки рекомендовал бы прочесть весь этот флуд 50 страниц. Тут много умного и вариантов так же много. Я свое видение высказал. И я к нему шел два года, раньше тоже контроллер мозгами был, а модель просто набором данных. Но за два года я таки понял что удобнее логику в модели хранить. Гораздо удобнее.
Удобнее это значит: требуется меньше кода, меньше времени, меньше усилий на поддержку.

Добавлено через 6 минут
И что самое крутое: роли таки получаются четко разделены. МОдель перестает быть тупой пачкой геттеров-сеттеров и начинает выполнять какие-то функции. И контроллер не раздувается до вселенских неконтролируемых масштабов.

У тебя много противоречий например ты говоришь:
имеешь в виду, что никакие данные не меняются в модели 30 раз в секунду.
а дальше
данные меняются 30 раз в секунду только в модели.
What? Я так не могу...

В моделях у меня таймера. Самый частый из них - раз в секунду. А это реже чем раз в кадр в целых 30 раз (у меня в проектах вообще обычно 60).

Добавлено через 5 минут
И это как правило вообще один глобальный теймер с частотой раз в секунду. В нем добавляются/удаляются коллбеки которые собственно на каждый тик дергаются.

Если нужна рекция чаще чем раз в секунду - есть еще одна глобальная штука - глобальный ентерфрейм. Ситема та же. Добавить/убрать коллбек и дернуть каждый - раз в кадр.

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

Dukobpa3, а как на счет ветвления контроллеров? В этом случае ничего раздуваться не должно. Может "пассиваная" модель и считается не правильным подходом, но при этом про ветвление этой структуры в той же википедии умалчивается (если где есть - дайте почитать, поделитесь ссылкой, интересно), а это предотвращает раздувание контроллера. При этом имеем четкое "разделение власти". Все же считаю, что программа не должна зависеть только от данных (как это может пропагандироваться), но и, к примеру, от "состояний". Где должно храниться "состояние"? Возможно в модели. Да, несколько озадачивает. В чем тогда предназначение контроллера? Список интерактивных объектов с подписанными слушателями и обработчиками и все?

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

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

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

Добавлено через 1 минуту
А вот хз))))
Я всунул туда же где и глобальный таймер. Просто в один и тот же синглтон можно добавить либо коллбек на таймер либо на ентерфрейм. И этот синглтон только этим и занимается - дергает периодические коллбеки с заданным интервалом. Иногда синхронизируя текущую дату с сервером.

Добавлено через 4 минуты
Связующее звено.
- слушает вью
- слушает другие контроллеры
- по командам от вью либо от других контроллеров может попросить модель поменять данные
- либо передать какую-то команду другим контроллерам.
- всё.

В нем вполне достаточно будет логики и кода для обработки разных команд от вьюх и других контроллеров. На этом его функция как для меня и заканчивается.

Примерно это и имел ввиду.
Какое это имеет отношение к роли модели? В любом случае модуль - не один файл, а группа из M, V и C. К тому же не забываем про интерфейсы.

Добавлено через 2 минуты
Dukobpa3, так кто все-таки меняет данные? Вью или контроллер? Получается, что оба. Получается, что мы можем не знать кто именно, хотя это один из основополагающих моментов.

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

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

Ну и получается контроллеры это типа как стартовые точки модулей.

Добавлено через 40 секунд
что значит "меняет данные" ?

Добавлено через 2 минуты
Вью ВПРИНЦИПЕ ничего не меняет. Она может попросить контроллер их поменять, а контроллер может и не согласиться.
И контроллер не меняет данные, он просит модель АКТУАЛИЗИРОВАТЬ ДАННЫЕ согласно текущего состояния системы. А модель уже сама вкурсе где взять конкретные цифры и куда их вписать.

В моём случае, например нужно перемещать главного героя нажатием клавиш, при твоём подходе вьюха самодостаточная - имеет весь функционал для данного действия, она сама прослушает нажатие, сама переместит в ентерфрейме объект и отрисует его. Зачем нужен контроллер и модель?

Чуток не так.
Переместить героя - скорее всего нужно будет помнить его последнюю позицию, значит она должна оказаться в модели.

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


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

А теперь другой вариант. Всё это должно синхронизироваться с сервером. Тогда:

- тыкаем в клетку на карте
- вью диспатчит: "пытаемся походить"
- контроллер получает событие, посылает команду контроллеру сервера: командаПоходитьВТочку(х, у)
- сервер обрабатывает, присылает ответ ок/неОк.
- какой-то серверКонтроллер кричит контроллеру карты мол тут команда пришла поменять координаты
- наш контроллер получает эту команду
- дергает паблик в модели: "походитьГероемТуда-то" (координаты пришли в событии)
- модель в этом паблик методе меняет координаты героя, и диспатчит: "координаты героя поменялись"
- вью слышит что координаты поменялись, переставляет героя в новые координаты.

Добавлено через 4 минуты
Т.е. Если модели нужно знать новые координаты то надо диспатчить в контроллер, а контроллер просит модель проверить можно ли и если можно - сделать.

Если модели знать не обязательно - то вью может быть "самодостаточной" как ты и сказал.

А теперь самое главное.
Как понять когда же модели нужно знать а когда не нужно:
- если на это новое состояние будет опираться математика - нужно.
- если это чисто визуальная плюшка - пофиг.

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

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

Нет ни один из примеров не подходит у меня игра без сервера и не пошаговая, а реалтайм, ходим по событию клавиш, вид сбоку и физика Box2D. MVC для такой игры не подходит?
Так нужно ещё интернет порыть об этом паттерне. Хотя вариант ПсихоТигра убедительней. Расскажите кто нибудь кроме Дикобраза кто как поступает в MVC с ентерфреймом?

Не за что:)) Лол)

Добавлено через 44 секунды
Самое обидное что какой-то мудак даже в вики переписал правильный паттерн на тот который ты называешь: "вариант тайгера".
А раньше там было примерно то о чем я тут вещаю.

Я вот тут подумал, а правомерно ли говорить об MVC во флеш-проектах в полной мере? Думаю, что реально в проектах используется не 3, а 4 элемента:
1) Модель - ее предназначение дискутабельно в рамках данной темы, но данные она все же хранит
2) Вью - то, что рисует дизайнер в ИДЕ (да, именно такая структура бывает далеко не всегда, но, думаю, достаточно часто), а мы, к примеру, подключаем это в виде класса, который дергаем из swc.
3) Контроллер, который, по сути, является тоже вьюхой и одновременно контейнером для вью (п.2) - там как раз и происходит подписка на слушатели различных элементов и пр.
4) Собственно контроллер - один большой и важный, который содержит в себе глобальную логику, на мелочи не разменивается, к примеру, управляет состояниями приложения.

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

ЗЫ. туалет и ванная - потрясающие помещения: столько мыслей приходит.

Добавлено через 1 минуту
Dukobpa3, на счет переписывания вики - почитай историю. Там примерно одно и тоже. Правда я раньше некоторые моменты пропускал мимо :(

В общем, вам в раздел: "наиболее частые ошибки"
Вики мвц

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

По той статье всё что здесь писали не правильно.

а ты прочел всё что здесь писали?)))))

Переубедил, хотя не ты а Википедия, да то что писал ПсихоТайгер не сходится с классическим активным MVC. Контроллер реализует только интерфейс с пользователем - ввод с клавиатуры и ввод с вьюшки, таким образом только соединяет модель и представление, в одну сторону от вьюшки в модель, модель всё решает, что делать с этим вводом и результат отдаёт в вьюпорт.
Понятно всё, почему-то в голову приходят сразу такие программы как Фотошоп, например всё что мы видим - делал один отдел программистов, а всё, чем думает программа - другой отдел, потом это соединили контроллером.
Зачем в начале темы так тщательно описан не правильный подход с пассивной моделью?

у тигры спроси

Добавлено через 30 секунд
Я там выше говорил, не за что ;)

Ты не убедил из-за того что сам путался
http://flasher.ru/forum/showpost.php...&postcount=490

Цели убеждать нету как бы. Ты спросил я ответил)

Но спасибо всё равно, а то не правильным путём пошёл-бы.

Добавлено через 14 минут
Что-то и мне так кажется, в силу того, что у нас есть такие высокоуровневые классы как Sprite где и View и кусок Controller'а уже вроде как реализованы. Спрайт-то и отображаться может и события рассылать, осталось только модель добавить. Может по этому в начале поста выдумывают всякое?

Sintesis, не стоит относиться к этому посту, как к непреложной истине. Тигра старался как мог, но все мы люди: можем ошибаться, и на всех не угодишь. Но те статьи, что он написал были рождены не одной темой на форуме или статьей на вики. Даже если делать не так, то прочитать, думаю, стоило бы однозначно. Мне вот все покоя дубовый стол не дает :)

Нужно учитывать что могут быть всякие композиции типа:
MV-C (Модель и вью в одном классе)
MC-V (модель с контроллером в одном классе)
M-CV (Вью с контроллером в одном классе)

И в таком духе.

Добавлено через 1 минуту
Я там выше говорил: главное четко для себя осознать роль каждого из составляющих М, В, Ц.
А там уже можно делать как больше нравится, главное чтоб самое суть оставалась.

Я к тому, что создавая проект в флеш девелоп например - точку входа наследуем от Спрайт и она автоматически у нас становится VC так как наследует и дисплай обжект и ивент диспетчер.

Диспатч ивента это одельная муть совсем. Каким иначе образом ты подпишешься контроллером на вью. А эта подписка предусмотрена в "академической" модели мвц.

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

У меня вообще контроллеры общаются посредством своего обсервера. Совсем отдельно от событий.

Добавлено через 39 секунд
С таким же понтом можно сказать что и модель тоже контроллер, она же как-то диспатчит вьюхе об изменениях.
Но это будет неверная формулировка.

В вьюхе не должно быть условий if? Это к логике относится?

Я вопроса не понимаю.
Это просто условие.

например:

Ну говорят, что вьюха тупая, а if(){} это уже подумать нужно: "если так - то сделаю это, если не так - то не буду этого делать"

Вьюха может содержать логику касающуюся отрисовки.
Вьюха не может содержать логику касающуюся математики.

Разница в том что в первом случае от решения вьюхи никого кроме нее не зацепит
Во втором - от решения будет зависеть какая-то цифра которая повлечет за собой последствия.

О таких вещах очень сложно говорить без примеров. Давай конкретные вопросы, а то это всё больше начинает напоминать демагогию.

Ага, спасибо, это нужно знать!
Пример такой: вьюшке нужно узнавать на каком этапе сейчас приложение, например если в модели стоит startMenu:Boolean = true; то она отобразит нужные кнопки и нужную графику. Значит можно сделать в вьюшке так:

Прочти наконец-то тему сначала и до конца!!!
Я это уже раз третий так точно тут же объясняю....