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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

in vino veritas

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

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

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