Хорошее MVC

[Волгоградец]

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

[Psycho Tiger]

Примеры? Были долго тупые бока, из-за того, что (в терминах MVC) вьюха меняла модель. Причем все отлично знали, что такое делать нельзя

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

Передача данных во вьюху только по значению - единственное, что спасло бы, но как-то оно не гибко.

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

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

MC+V?

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

Можно и синглтон в качестве центральной логики использовать. Прелести MVC вылезают где то после полмегабайта "свежего" кода - т.е. кода, написанного только под этот проект. Кружочки-кругляшки я говорил абстрактно, имея ввиду что отображаем кое-как, а игра работает правильно.

Чем при MVC легче? "Рисуем сверху", "рисуем сзади" придется писать примерно одинаково, разрулить, когда как рисовать - никаких проблем.

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

Но практика взрывает мозг.

Ты сам виноват, начав консультироваться сразу по композитным MVC)

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

Не, модель не передаёт команд. Модель говорит о том, что изменилась - а вьювер сам принимает решение, стоит ли ему новые данные визуализировать или нет.

Как обрабатывать событие enterFrame?

enterFrame чего, вьюхи? Типа очки плавно возрастают с 0 до 500? Это заботы сугубо вьюхи, в модели было значение 0, потом сразу стало 500.
Если речь о нужде события enterFrame в контроллере - тот создаёт DisplayObject и хватает у него этот enterFrame. Композиция, короче.

[Котяра]

ну по энтерфрэйм/таймеру можно менять модель тоже (например xPos,yPos,zPos)
а во вью это отображать.
так у меня сделана одна 3D стрелялка.
вью в этом случае это viewport камеры, модель - это координаты 3D объектов.
делать каждый 3D объект вьюшкой нельзя. вернее они тоже вьюшки, но другого уровня - слушают например поле модели статус и исходя из него меняют свою текстуру/форму.
Но вообще в таком случае чистый мвц не очень подходит.

[etc]

Сообщение от -De-

Присоединяюсь к вопросу - зачем нужно MVC на флэше?

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

[Волгоградец]

Не, модель не передаёт команд. Модель говорит о том, что изменилась - а вьювер сам принимает решение, стоит ли ему новые данные визуализировать или нет.

Да, я это и имел ввиду. Скажем каждый кадр у меня куча партиклов рисуется. Т.е. контроллер считает позиции и должен их в модель передать, так (ну если это тру MVC)? Ну а модель диспатчит во вьювер эти новые позиции. Замороченно как-то.

Но вообще в таком случае чистый мвц не очень подходит.

\
Вот. И это уже тогда не MVC получается - а просто архитектура. А так как во флэше все привязано к enterFrame - нужен ли вообще нам MVC?
P.S.: но это так - нубские мысли. Все равно у каждого свое видение паттернов.

[etc]

Сообщение от Волгоградец

Вот. И это уже тогда не MVC получается - а просто архитектура. А так как во флэше все привязано к enterFrame - нужен ли вообще нам MVC?
P.S.: но это так - нубские мысли. Все равно у каждого свое видение паттернов.

ENTER_FRAME это просто периодическое событие. Не понимаю, каким образом оно нарушает MVC.

[Bgg]

По моему, как минимум в gamedev'е рано или поздно все равно приходишь к MVC. Как не крути, слишком уж удобно отделять представление от данных и всем этим управлять контроллером. Потому не вижу смысла насильно разбираться в паттерне, который видимо просто негде пока применять.

[Zebestov]

Много читал/спрашивал/планировал и пришел к выводу смещения мозгового центра из Controller в Model:

Model
Хранит статические данные, состояния и прочее. При поступлении команд на изменение реализует логику по изменению состояния, сообщает об изменениях.

View
Элемент с двойственным характером. С одной стороны он на свой лад отображает данные из модели и следит за актуальностью этого отображения.
С другой стороны еще реагирует на действия пользователя (как правило мышь, клавиатура). Но мышью можно кликнуть по кнопке, сменить состояние CB, сдвинуть ползунок, что там еще? Модель не должна в этом ковыряться, ей нужен четкий сигнал с конкретным значением конкретного свойства/состояния.

Controller
Самый тонкий элемент системы. Его задача принять сообщение от View, и на основании этого сигнала выдать простое и понятное сообщение. Например вместо "слайдер яркости в состоянии 80" модель уже получит "яркость 0.8". И поменяй я во View слайдер на числовое поле или CB — контроллер переписал и готово. А модель и не прознает.

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

[Psycho Tiger]

Мозгом системы является контроллер. Представь ситуацию: ты решаешь задачу и пишешь мысли в тетрадку, там её решаешь. Ты - контроллер, тетрадка - модель.

Скажем каждый кадр у меня куча партиклов рисуется. Т.е. контроллер считает позиции и должен их в модель передать, так (ну если это тру MVC)?

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

[Котяра]

2Zebestov
немного меня смущает подмена понятий модели и контроллера у тебя.
модель

При поступлении команд на изменение реализует логику по изменению состояния

и контроллер

и на основании этого сигнала выдать простое и понятное сообщение

модель не должна реализовывать логику - это прерогатива контроллера.
контроллер не выдаёт сообщений он явно меняет модель.