[dimarik]

Классический способ реализации метапаттерна MVC описан в вики. Это упрощенная схема работы комплексных (complex — составной) блоков, состоящих из других паттернов. В моей практике все блоки я реализовавал из шаблонов GoF.

От задачи все не сильно зависит, да простит меня камрад in4core...

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

Я рассуждаю о модели в паттерне MVC как о Вселенной: на её физические законы не влияют (но это не точно) наши рассуждения, мнения и вообще наш Homo sapiens разум. Законы природы везде работают одинаково. Законы природы просто есть и они действуют без нашего участия. Неважно в каком диапазоне волн воспринимают визуально мир люди, собаки и кроты. Мы есть только вьюхи в шаблонах Вселенной ). И, кстати, на нас можно давить с помощью контроллера модели (например, погоды) и мы станем утепляться или, наоборот, постараемся найти прохладу.

Модель в паттерне MVC сама в себе и она самодостаточна. Она получает данные от контроллера, да. И выдает переработанное и осмысленное состояние всем вьюхам, подключенным к этой модели. Если контроллер сказал, что температура за бортом -60°, то модель просто не начнет выращивать курочек для фермы -- слишком холодно. Зато она начнет производство льда в промышленных количествах.

По вопросу камрадов

Сообщение от undefined

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

и

Сообщение от ZergMaster

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

Отвечу... Какие данные и в каком виде нужно отсылать серверу должна знать модель. Для модели сервер есть самая обычная вью. Как это ни странно. В картинке из вики вверху поста нет понятия "сервер". Зато есть понятие "view".
Тут нужно пояснение. Данные, находящиеся в модели должны пройти через сериализатор, предназначающийся для конкретной серверной платформы. А возможно и не серверной, если вы просто сохраняете стейт модели в файловую систему. Это существенное дополнение. На самом деле роль сериализаторов и десериализаторов (парсеров) весьма серьёзна. Я видел проект, в котором десериализация данных была в самой модели. Это ставит модель в зависимость от вида внешних данных (JSON, XML, YAML, custom protocol). Не делайте так. Сериализация/десериализация должна быть внешней по отношению к модели и осуществлена с помощью контроллера.

Сообщение от Appleman

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

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

Сообщение от undefined

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

Холивара немношк. Да, это нормальное явление и модель знает о своем состоянии лучше контроллер(а/ов). Именно она хранит свой стейт и сообщает об его изменении хорошей вьюхе. Камрад Zebestov, наверняка, погорячился. Потому что ходом выполнения приложения заведует модель, а не контроллер. Такая вот «ТТУМ» («Толстая, тупая, уродливая модель»; Fat Stupid Ugly Model). Но это больше шутка. А по-другому на классике не сделаешь.