Хорошее MVC

[3p.station]

если каждое приложение достаточно уникальное, то смысл тогда в MVC ?
если я верно понял, то этот паттерн для того чтобы эту уникальность и разрулить и например одну и туже модель исопльзовать не один раз и не в одном проекте, а следовательно она должна иметь какието "правила" котороые можно будет исопльзовать в дургом проекте и при этом не думать об переделвании интерфейсов и способов связывания между модулями
хотя это лишь мне так поудмалось

а вот по поводу той статьи что ниже я скинул, - вникнул и понял что там не то ):
там чел внизу про это и напаисал в комментах и дал ссылку на википедию

[Psycho Tiger]

Смысл MVC как раз в унифицированном решении проблемы архитектуры, когда требуется отделить данные от представления от манипуляции с этими данными. Ну вот проще говоря, не мыслю как паттерн можно под гребёнку смести, не говоря уж об архитектуре. Рассмотрим паттерн адаптер: он может служить единым интерфейсом для 2-3 социальных сетей, а может служить для единых входных данных от входных устройств - проще говоря управление мышкой/клавиатурой/джойстиком. Единственное что между ними общего - "единый интерфейс для работы с..." - но в этом и суть адаптера. Если смотреть со стороны MVC - общее это может быть некий абстрактный объект контроллера, модели и вьюхи, у которых расставлены эти связи между трио. Но эти связи во всех 3 классах дай бог нагребут 150-200 строчек кода. Я не вижу смысла ради 1% кода в проекте подстраивать под него остальные 99.
Описанное выше - конкретно моё имхо). Наверно, стоит пощупать эти фреймворки чтобы делать такие категоричные заявления... но как то не тянет.

[3p.station]

когда требуется отделить данные от представления от манипуляции с этими данными.

вот эта отделенность как я понял для того чтобы можно было использовать любую часть в трио для других проектов, а следовательно должны быть какието "правила" их создания

вообщем если честно, еще гулбоко не вникал в роботлегс , как чего пойму отпишусь ( :

[Psycho Tiger]

Не совсем. В идеале для меня так:
Вьюшка - отображает. Очень удобно тем, что невозможно отображением подпортить логику игры. Добавил вспышку света при взрыве гранаты - и никак не может произойти так, что из за вспышки у врага на крыше упали штаны. Такие баги допустить очень легко, когда всё в куче. Ещё удобно тем, что разработку можно вести на уровне кружочки-квадратики и не ощущать скованность из за неполноты представления - добавляя отображение мы меняем 33% кода, вместо всей 100 (если представить что модель-контроллер-вьюшка имеют равный объем кода, что почти всегда неверно ). Очень удобно когда ещё люди не знают, как будет выглядеть игра. Есть логика игры, а вот над представлением ещё думают, есть мелкий концепт. Чертовски удобно когда несколько видов игры - например вид сверху и вид сзади (3д, но игра функционала такого же как в 2д).

Модель - ну тут в идеале - полная информация о процессе. Идеальная модель для меня - это если удалить вьюшка и контроллер, а потом создать их снова чистенькие и отдать эту модель - всё восстановится в точности/почти в точности, как было раньше. Очень удобно для сериализации: если она не DisplayObject - то просто записываем в ByteArray - получаем AMF объект, который можем сохранить... да хоть в файл. Некоторые в качестве модели используют DisplayObject`ы, ради иерархии и бабблинга событий. Врать не буду - в целом идея удобная, а сериализовывать модели... ну лично мне не приходилось никогда. С другой стороны DisplayObject`ы едят больше памяти, чем просто EventDispatcher`ы, так что эти моменты весьма спорные. Но это я от темы отхожу.

Контроллер - ерунда которая всем этим делом управляет и содержит все мозги.

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

[-De-]

Сообщение от Psycho Tiger

Вьюшка - отображает. Очень удобно тем, что невозможно отображением подпортить логику игры.

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

Сообщение от Psycho Tiger

Ещё удобно тем, что разработку можно вести на уровне кружочки-квадратики и не ощущать скованность из за неполноты представления - добавляя отображение мы меняем 33% кода, вместо всей 100 (если представить что модель-контроллер-вьюшка имеют равный объем кода, что почти всегда неверно ).

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

Сообщение от Psycho Tiger

Чертовски удобно когда несколько видов игры - например вид сверху и вид сзади (3д, но игра функционала такого же как в 2д).

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

[cleptoman]

чуть не растерял остатки мозга, пока все страницы осилил.
понял одно: я не тру и отсталый недофлэшер)

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

раздает данные детям.
слушает детей на предмет запросов на обновления инфы.

если есть сервер, то как правило есть поставщик данных, который пуляет запросы и диспатчит события( если чтонить прилетает) в главный класс, в удобной для меня форме.

понимаю как-то далековат я от MVC

[Psycho Tiger]

Понимание и прелести MVC приходит со временем. Поначалу начинаешь сам отделять управление от отображения, потом начинается разделение ещё и на данные, помимо отображения и управления, ну а потом осознание что визуализируются то данные, и по сути управление к отображению имеет мало отношения. И тут мы приходим к MVC..)

[-De-]

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

[etc]

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

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

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

[Psycho Tiger]

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

P.S. локализация и звуки это задачи сугубо вьюхи. к модели отношения не имеют.