[Паттерны] AS3 MVC

[namespaces]

Привет.
Создаю на Эйр небольшое приложение для телефона. Думаю все таки понять суть и создать свой кастомный MVC. До этого имел дело с PureMVC, Robotlegs, SomaFramework и т.д. Давно привык использовать готовые фреймворки, чем изобретать свой велик.
В общем, прочитав несколько статеек про MVC, вроде все ясно

var model:Model = new Model();
var controller:Controller = new Controller(model);
var view:View = new View(model, controller);
addChild(view);

Но везде пишут только про стартовый запуск паттерна, а как двигаться дальше? Скажем, если у меня 10 моделей, 20 контроллеров и дофига вьюшек, как все это связать в одно целое?

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

Буду очень благодарен за любые советы.

[Wolsh]

Бэкграунд является Данными приложения? Как говорится, нафига козе модель.

Добавлено через 2 часа 15 минут
Такой подход, действительно, распространен — когда "любое изменение на экране должно инициироваться Моделью". Но это вовсе не значит, что он хорош и обязателен. Это избыточность архитектуры.
Модель должна заниматься данными: хранить их и обрабатывать, производить вычисления и осуществлять логику Приложения. Если изменение фоновой картинки никак не влияет на логику приложения и его данные, оно никак не связано с Моделью. Ваше затруднение возникает из-за того, что Вы абстрагируете фоновую картинку в отдельную самостоятельную триаду MVC, создавая таким образом отдельное самостоятельное приложение "Меняющийся фон". В рамках этого приложения всё законно, есть модель, хранящая данные о всех картинках, текущей картинке, и вычисляющая следующую картинку и момент изменения, и посылающая событие для Вью. Вопрос только в том, нужна ли эта триада "главному" MVC Приложения, или может прекрасно существовать в его Вью. Ведь всё, чем "Меняющийся фон" занимается, имеет отношение только к Вью и никак не меняет данные самого Приложения. Если завтра Вы захотите поставить на фон видеоролик, или скриптованую 3D-сценку, это никак не отразится на логике Приложения. Это вопрос только отображения, и им должна заниматься Вью. Для того Вью и отделяли от Модели, чтобы совершенно свободно менять варианты отображения, не внося никаких изменений в логику.
Ну а после того, как Вы согласитесь, что место этой штуке — во Вью, скорее всего отпадет и необходимость оформлять ее как MVC: контроллеру там нечего контролировать, нет никакой интерактивности; нет Данных и логики, которые был бы смысл защитить в Модели. Есть только Вью со СКРИПТОМ, или, как говорили раньше, сценарием. Простым самодостаточным сценарием, независящим ни от чего.
Даже если смена картинки подразумевается не по таймеру, а при переходе Приложения к другому "разделу" или "состоянию", то это изменение является глобальным для всего Вью и должно инициироваться из Вью. То есть Вью получает от Модели событие смены Состояния, а смена картинки является частью реакции Вью.

[namespaces]

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

Бэкграунд является Данными приложения? Как говорится, нафига козе модель.

Спасибо за развернутый ответ.
Насчет бекграунда скорее всего так и сделаю. Это просто был пример.

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

[Wolsh]

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

Это Модель.

А также несколько окошек, игровую сцену, звуки и т.д.

Это Вью.

Вопрос лишь в том, как Вид слушает ответ от 5 моделей?

MVC это не паттерн, а парадигма. Паттернов в нем может быть еще десяток разных. Если Вам действительно необходимы 5 моделей (а это не факт), можно сделать им Фасад. Можно и не делать, а иметь 5 "независимых" MVC. Это уж надо решать в конкретной ситуации.

Какая роль у контроллера?

Разделить Вью и Модель так, чтобы не было жесткой связности. То есть, чтобы Вью не пришлось импортировать Модель (что явный нонсенс). Вообще, в отличие от вашего представления в первом посте, Вью и контроллер-то не импортирует и не имеет на него ссылки. Потому что Вью должна только посылать события о том, что юзер сделал то-то и то-то. У Вью нет логического языка, то есть Вью не может формулировать сообщения в виде "юзер убил танк №112". Вью не берет на себя логику. Вью может сообщать только "юзер нажал клавишу Пробел". И вот здесь, по парадигме MVC, включается контроллер, поскольку Модель живет в своем мире Данных и понятия не имеет ни о каких клавишах и мышках. Контроллер — тот, кто Знает, что именно в текущем режиме Приложения делает клавиша Пробел. Какой именно метод Модели надо вызвать. Потому что в режиме Меню клавиши "делают" одно, в режиме Чата другое, в Инвентаре — третье, а в бою — четвертое. Контроллер контролирует действия юзера в зависимости от режима (mode), в котором находится Приложение. Переключение этих режимов может менять сами контроллеры (почему, собственно, выгодна схема с событиями от Вью а не вызовами методов контроллера напрямую — замена контроллера в такой ситуации была бы крайне затруднительна). Таким образом контроллеры инкапсулируют в себе поведение. Не логику Игры, не вычисления, а именно трактовку действий юзера в условиях текущего Состояния приложения, характер интерактива. Потому что эту трактовку не может себе позволить ни Вью, максимально удаленная от логики и данных, ни Модель, максимально удаленная от способа отображения данных и взаимодействия с пользователем.

[namespaces]

Теперь все стало понятно, разложили все по полочкам. Спасибо за помощь.