Хорошее MVC

[Dukobpa3]

В любом случае модуль - не один файл, а группа из M, V и C.

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

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

Ну и получается контроллеры это типа как стартовые точки модулей.

Добавлено через 40 секунд

Dukobpa3, так кто все-таки меняет данные?

что значит "меняет данные" ?

Добавлено через 2 минуты
Вью ВПРИНЦИПЕ ничего не меняет. Она может попросить контроллер их поменять, а контроллер может и не согласиться.
И контроллер не меняет данные, он просит модель АКТУАЛИЗИРОВАТЬ ДАННЫЕ согласно текущего состояния системы. А модель уже сама вкурсе где взять конкретные цифры и куда их вписать.

[Dukobpa3]

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

Т.е.:
- тыкаем в клетку на карте
- вью диспатчит: "пытаемся походить"
- контроллер получает событие, дергает паблик в модели: "походитьГероемТуда-то" (координаты пришли в событии)
- модель в этом паблик методе делает проверку. Можем походить, не можем и если можем то меняет координаты героя, и диспатчит: "координаты героя поменялись"
- вью слышит что координаты поменялись, переставляет героя в новые координаты.


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

А теперь другой вариант. Всё это должно синхронизироваться с сервером. Тогда:

- тыкаем в клетку на карте
- вью диспатчит: "пытаемся походить"
- контроллер получает событие, посылает команду контроллеру сервера: командаПоходитьВТочку(х, у)
- сервер обрабатывает, присылает ответ ок/неОк.
- какой-то серверКонтроллер кричит контроллеру карты мол тут команда пришла поменять координаты
- наш контроллер получает эту команду
- дергает паблик в модели: "походитьГероемТуда-то" (координаты пришли в событии)
- модель в этом паблик методе меняет координаты героя, и диспатчит: "координаты героя поменялись"
- вью слышит что координаты поменялись, переставляет героя в новые координаты.

Добавлено через 4 минуты
Т.е. Если модели нужно знать новые координаты то надо диспатчить в контроллер, а контроллер просит модель проверить можно ли и если можно - сделать.

Если модели знать не обязательно - то вью может быть "самодостаточной" как ты и сказал.

А теперь самое главное.
Как понять когда же модели нужно знать а когда не нужно:
- если на это новое состояние будет опираться математика - нужно.
- если это чисто визуальная плюшка - пофиг.

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

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

[Sintesis]

Нет ни один из примеров не подходит у меня игра без сервера и не пошаговая, а реалтайм, ходим по событию клавиш, вид сбоку и физика Box2D. MVC для такой игры не подходит?
Так нужно ещё интернет порыть об этом паттерне. Хотя вариант ПсихоТигра убедительней. Расскажите кто нибудь кроме Дикобраза кто как поступает в MVC с ентерфреймом?

[Dukobpa3]

Не за что) Лол)

Добавлено через 44 секунды
Самое обидное что какой-то мудак даже в вики переписал правильный паттерн на тот который ты называешь: "вариант тайгера".
А раньше там было примерно то о чем я тут вещаю.

[TanaTiX]

Я вот тут подумал, а правомерно ли говорить об MVC во флеш-проектах в полной мере? Думаю, что реально в проектах используется не 3, а 4 элемента:
1) Модель - ее предназначение дискутабельно в рамках данной темы, но данные она все же хранит
2) Вью - то, что рисует дизайнер в ИДЕ (да, именно такая структура бывает далеко не всегда, но, думаю, достаточно часто), а мы, к примеру, подключаем это в виде класса, который дергаем из swc.
3) Контроллер, который, по сути, является тоже вьюхой и одновременно контейнером для вью (п.2) - там как раз и происходит подписка на слушатели различных элементов и пр.
4) Собственно контроллер - один большой и важный, который содержит в себе глобальную логику, на мелочи не разменивается, к примеру, управляет состояниями приложения.

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

ЗЫ. туалет и ванная - потрясающие помещения: столько мыслей приходит.

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

[Dukobpa3]

В общем, вам в раздел: "наиболее частые ошибки"
Вики мвц

[TanaTiX]

Dukobpa3, читал я этот раздел. Могу конечно ошибаться, но почему-то мне кажется, что та статья не учитывает специфику флеша. А может это и сила привычке во мне говорит. Вообще надо как-нибудь задуматься, чем плох/хорош используемый мной подход (в т.ч. и сам паттерн), чего бы хотелось и, соответственно, как это все реализовать.

[Sintesis]

По той статье всё что здесь писали не правильно.

[Dukobpa3]

а ты прочел всё что здесь писали?)))))

[Sintesis]

Переубедил, хотя не ты а Википедия, да то что писал ПсихоТайгер не сходится с классическим активным MVC. Контроллер реализует только интерфейс с пользователем - ввод с клавиатуры и ввод с вьюшки, таким образом только соединяет модель и представление, в одну сторону от вьюшки в модель, модель всё решает, что делать с этим вводом и результат отдаёт в вьюпорт.
Понятно всё, почему-то в голову приходят сразу такие программы как Фотошоп, например всё что мы видим - делал один отдел программистов, а всё, чем думает программа - другой отдел, потом это соединили контроллером.
Зачем в начале темы так тщательно описан не правильный подход с пассивной моделью?