dimarik,вот по твоему опыту на сервер данные слать должна модель?Тут несколько раз возникала идея что это работа для контроллера.По мне так контроллеру вовсе незачем знать кухню модели и протокол общения с сервером.
Вики говорит, что можно и так и так,но предостерегает от «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers).Интересует твое мнение по вопросу.

undefined, дружище, пожалуйста, прекращай троллить ).

dimarik - моя трактовка вполне как раз нормальна. Ты забываешься, что проекты разные, и каждый работает с разными приложениями и играми. В твоем случае - модель может быть ГЛАВОЙ приложения ( в твоем случае, всмысле в твоих проектах) , в более простых же проектах, модель обычно коробка данных. - Давай рассмтрим простой пример пинг-понга скажем. 2 дощечки и шарик. Вьюха хватает события мыши(клавы) и т.п. проверяет на хитТест попадание шарика, диспатчит ГОЛ, контроллер ловит событие и запускает процесс в моделе типа ГОЛ++. В данной игре кроме как счетчик голов, счетчик SCORE и т.п. в моделе ничего не будет, и да это будет безмозглая коробка данных. Это если по простому, можно конечно начать изврат = и делать модель завязанную на всю логику, в таком простом приложении, это называется too much
По топик стартеру - задавая такие вопросы, которые он задает, рано лезть и писать ММО, а значит ему пока надо научится на простых проектах. Сразу лезть в дебри и настроить себе голову так, что модель это основа - сможет только бывалый, вспомни как ты начинал, у тебя и мыслей таких не было.

undefined - учитесь оптимизировать приложения. Если ваш контроллер становится толстым, значит подход неверный. У меня обычно контроллер( base ) кроме как запросы к серверу и получения данных ( + работа с моделью соответсвенно) ничего не делает, в крайнем случае можно дернуть вью из контрола пользуясь MVP - но это обычно ровно столько методов, сколько запросов к серверу. И я опять же не претендую на знание гуру MVC - mvc - он такой, какой тебе надо, а не такой который тебе навязывает то один, то другой, когда голова начинает у некоторых идти кругом.

in4core, не соглашусь. Уже много раз оговаривалось, что модель — это ядро приложения.
В пинг-понге вью передает контроллеру сообщение о том, что что делает игрок (вьюха сама разруливает, каким именно образом игрок воздействует на смену направления и скорости движения палки). Контроллер эту информацию передает модели, мол, там палку в другую сторону потянули. Именно модель определяет, гол или нет. Если да, модель гавкает об изменении счета или о геймовере. Первое ловит сама вью и перерисовывает табло. Второе ловит контроллер и действует согласно заложенному воркфлоу. Он сообщает вьюхе, чтобы она сворачивала игру и разворачивала сообщение, что игрок продул. От нее же контроллер ждет, что там игрок решил: разбить приставку о стену или таки нажать что-то там (контроллеру на это пофиг — это может быть нарисованная кнопка или хоткей) что означает "давай еще раз!!"

Други! Сидел, читал с интересом дискуссию профи, а пока созрел ещё вопрос по MVC. В моём проекте (по-прежнему, это игра на механике текстового квеста) всё взаимодействие с пользователем строится через последовательно выводимые ему текста и изображения (всякие шкалы и портреты пока не в счёт). Сейчас это работает так: Модель, делая расчёты, набивает в массив инструкции. Каждый элемент - экземпляр класса-наследника ViewInstruction. Когда посылается событие на отработку этих инструкций, Вью начинает его разбирать, вынимая и анализируя каждый элемент массива вот таким образом:

Уже вижу сам, что подход хреновый. В главной Вью получается мясо из деталей этих инструкций. Хочу реализовать что-то типа паттерна GoF "Стратегия", т.е. реализовать в каждой из инструкций метод типа execute(), чтобы Вьюха, "достав" из массива очередную инструкцию, не разбиралась в нюансах, а просто запускала её. Плюс такой подход позволит добавлять новые возможные инструкции. Но тут возникает вопрос, на который я хотел бы получить мнения знатоков.

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

И ваще не париться :) Но смущает многократно услышанные здесь от компетентных людей рекомендации о недопустимости передачи ссылок на родительские объекты детям и т.п. Собственно, просьба прокомментировать. Спасибо.

Почему бы вьюхе не ловить гамовер раз уж в каноническом mvc события от модели слушает только вью?

Потому что ходом выполнения приложения заведует контроллер и не вьюхе решать, что будет дальше после того, как игрок проиграл. Это может быть таки геймовер, это может быть rewarded video ради продолжения и такое прочее. Все это рулит контроллер — это практически единственная его работа, направлять ход приложения от пункта к пункту. Дело вьюхи сидеть на попе ровно, рисовать, что скажут, и сообщать, куда там игрок тыцнул.

да,резонно

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

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

ZergMaster - именно об этом я и писал, слово в слово.

Zebestov - дружище, вот ничем не отличается твой пример собственно от моего, лишь тем, что модель решило гол или не гол. Хотя - даже чисто математически смотри -
if(sharik.x < 0) dispatchEvnet(gol...) model-> aga gol Это я к тому, что я уже на этапе вью знаю гол или нет, нафига мне передавать каждый раз координаты в модель, или же вообще постоянно апдейтить это на таймере в моделе, чтобы модель узнала гол произошел или нет? Что за злобное рпограммирование?

Добавлено через 6 минут
Не надо ничего себе усложнять - мвц - это инстуркции к применению, а не злобный смотритель с палкой. Тут 100500 людей, и большинство тем или иным способом юзает этот паттерн - и 100500%, что у каждого он СВОЙ, просто потому, что каждый пишет так, как ему удобно, НООО - есть большое но, есть конечно и нюансы, где перегибать палку не надо, если ты из view.model.method() делаешь - бить по рукам, а если у тебя gfx логика во вью, а модель только сборщик данных ( как это реально работает в слотах ) , а контроллер общается с сервером и напрямую работает с вью по мвп моделе, это не есть ох и ах, это один из методов организации приложения.