События, влияющие на ход работы приложения от пункта к пункту, слушает контроллер.
События, требующие визуализации актуального состояния, слушает вью.
Как-то так.

Вот ты объясни человеку о чем ты говоришь на примере. Какие события слушает вью это и так всем понятно. А вот что значит от ПУНКТА к ПУНКТУ. Давай построим простейший пример, чтобы всем было понятно о чем ты пишешь. Как минимум вот на твоей же и игре в подписи.
а) сколько у тебя контроллеров или он один?
б) сколько у тебя моделей? ( если ли общая модель, или же просто разрозненные типа PlayerModel, IFaceModel и т.п. )
в) Что у тебя происходит в иерархии событий и т.п. когда игрок движется вправо-влево, что происходит , когда ловит яблоко?

Я как обычно не претендую на гуру, но как по мне в данной игре достаточно всю логику спокойно уместить во вью, а контроллером только посылать на сервер скоре игрока и т.п. , а модели чисто хранить какие то данные, ну и совсем малость где, обновлять вьюху, но это прям 1-2 метода не более.

Контроллеров несколько, дерево.
Моделей несколько, тоже дерево.
Вьюх тоже несколько, и да, опять дерево.
Главный контроллер проводит игру по кругу: меню-игра-меню-игра… "от пункта к пункту".
Контроллер слушает свою модель и свои контроллеры. Например MainController ждет от MainMenuController событие "CLOSE". Дождался — приложение идет дальше — GameController.open(), предварительно подписавшись на его CLOSE. Тот же GameController в свою очередь слушает от GameModel событие GAME_OVER и решает, что делать дальше, после того, как персонаж "запаркуется" на стартовой позиции (тоже по событию от модели поймет): откатать рекламу, например, или сразу посылать событие CLOSE, чтобы MainController снова открыл меню. Таким образом контроллер(ы) заведуют движением приложения.

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

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

Кроме отображения информации, важной для игры GameView делает еще вещи, которые вообще не должны волновать ни модель, ни кого-либо другого: анимирует появление яблока из листвы, топает ножками персонажа и т.д.

Ну вот условно так.

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

Модель работает с данными. Данные приходят извне. Можно использовать подход, когда в модели есть свой механизм Serialize/Deserialize, заточенный на конкретный протокол данных, который целиком передается этому механизму, но это не очень хорошо, потому что ее невозможно без переделок использовать в другом окружении. А можно внешним, легкозаменяемым десериализатором распарсить данные и скормить модели через сеттеры, например. Короче встроенный в модель десериализатор не так удобен.

Добавлено через 10 минут
Могут быть условия, при которых нельзя делать model.plus(). И контроллер знает об этом, а вью — не должна в принципе. В данном случае контроллер реализует паттерн "Посредник". Поэтому все нормально в парадигме.

Добавлено через 17 минут
Такая же фигня, братюня )

Дима
Тут двоякое ощущение от твоего ответа. Во-первых, что значит могут быть условия? Вот я например один реализовал приложение, и я знаю, что нет таких условий, и только там где надо я это сделаю например. Во-вторых даже если это будет скажем приложение написанное командой, то никто не мешает вставить * коммент о том, что больше нигде так не делать. - ну это конечно понятно, что правила хорошего тона, и в этом случае все таки нельзя.
А двоякое ощущение, потому что ты пишешь слегка непонятно, *все нормально в парадигме* - это значит ты не запрещаешь раз в 100 лет дернуть метод модели из вью? Или ты говоришь наоборот, что парадигма должна быть выполнена как положено, клик вью, пересылка в контрол, пересылка в модель, рассылка всем ???

Добавлено через 1 минуту
Да я тут проездом) Просто скучно стало. Скоро убегу опять, на пару лет)

А что подразумевается под Serialize/Deserialize? Парсинг запроса/ответа в json/строку? Так такое обычно отдается serverManager'у, который сериализует реквест в стринг, шлет на серв,получает респонс и кастует его к ожидаемому типу. Как иначе то?

Бывает, люди пихают всю сериализацию в модель напрямую (т.е. в базовом классе модели объявляют serialize/deserialize, где и вызывается условный `JSON.parse`).
Имеется ввиду, что самый ок вариант – это когда есть условный `ISerializator`, который всем этим и занимается. Весь код приложения к нему, по большей части, агностичен.
Юзкейс: проверять доступность транспорта до тех пор, пока не найдется лучший.
Например: используем [веб]-сокеты, если клиент/платформа может в них. Если нет, то long-polling (это когда HTTP request висит в "ожидании" до тех пор, пока данные не пришли). В первом случае сериализуем в бинарном виде компактненько, во втором – только жирно строками (json/base64/xml/etc).
(Конечно, юзкейз требует ещё и `IServerConnector`, которых тоже два – слать в сокет и слать хттп реквесты – суть та же самая)

Разъяснил как мог:

Ну, кастовать Object к ожидаемому типу, если ожидаемый тип конкретнее, чем Object, скорее всего, не получится. Как говорится "Мы кастовали, кастовали, да не выкастовывавали".

Десериализация — процесс перевода последовательности битов в структуру данных (via wikipedia). Парсинг, а точнее, синтаксически анализ, это и есть часть процесса десериализации.

В случае, если модель будет работать с JSON, то произойдет такая цепочка (вариант 1):
1. Чтение из источника потока байтов (файловая система или сетевой протокол), представляющих собою plain текст, который полностью подчиняется грамматике JSON;
2. Преобразование текста (десериализация и парсинг) в ActionScript Object;
3. Чтение полей из этого Object и заполнение полей конкретного объекта(ов) модели.

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

Пример: есть протокол AMF1/3, с помощью которого происходит десериализация данных непосредственно в strong typed объект ActionScript. Однако с помощью него нельзя переписать поля существующего объекта. Десериализация потока этого протокола средствами флеша всегда приводит к созданию новых объектов.

Так вот десериализатор из второго пункта "варианта 2" может быть:
а) встроен в объекты модели;
б) внешним по отношению к объектам модели.

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

Пункт "б" предпочтительнее. Некто извлекает из модели объект и сам пишет в него. Затем повторяет.

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

и это все лишь бы не создавать новый объект на каждый респонс?Оно того не стоит имхо.