Хорошее MVC

[etc]

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

[Dukobpa3]

Мой MVC не совсем академический, так как модель как правило выполняет роль БД, а вся логика в контроллере, и частично во вью (но разделение логики контроллера и вью четкое: контроллер решает те вопросы в которых требуется изменение модели, а так же коммуникации с другими контроллерами, а вью сугубо то что нужно менять визуально).

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

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

Там пара: модель + контроллер.
Соответственно контроллер запускает таймер, а модель хранит в себе неформатированное время. Плюс это время периодически синхронизируется с сервером.

А все вьюхи уже берут эту цифру и показывают кому как надо.

[ir73]

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

[etc]

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

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

Старшая вьюха и создаёт.

[ir73]

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

Старшая вьюха и создаёт.

создает да, а добавляет кто (addChild)? контроллер? откуда у него ссылка на какой-то из внутренних displayobject container-ов?

[Dukobpa3]

Если можно я отвечу, хоть вопрос и не ко мне)) Так же под шумок возможно кто-то укажет и на мои ошибки в понимании данного вопроса

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

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

[Dukobpa3]

Дерево растет из мейна. Мейн - это хост мейн контроллера. Ну и дальше аналогия с дисплейлистом идет. Хосты друг в друга добавляются согласно места в дереве.

[etc]

Создаёт — это и есть new с addChild. Контроллер построением интерфейса не занимается.
Если это компонент (окно, например), то связыванием контроллера с компонентом занимается какой-нибудь менеджер компонентов. Или же контроллер компонента им же самим и создаётся.

[crazyone]

Раз уж пошла такая пьянка, расскажите мне пожалуйста, как организовывается многокнопочный интерфейс.
Ну, вот если есть панель управления, на которой 100500 кнопок типа загрузить картинку, загрузить документ, загрузить музыку, загрузить видео и т.д. Кто слушает все эти кнопочки и решает что дальше делать?

В голову просится ответ, что вьюшка слушает детей на предмет MouseEvent.CLICK, а потом диспатчит кастомное событие InterfaceEvent.LOAD_FILE с соответствующими свойствами.
Точно так же - если мы захотим повесить хоткеи на эти кнопки, то вьюшка будет слушать KeyboardEvent.KEY_DOWN и вещать те же самые события.

Но что-то внутри меня подбивает сделать обработку изначальных MouseEvent.CLICK и KeyboardEvent.KEY_DOWN уже в контроллере, т.к. это какбе уже принятие решения - как реагировать на действия пользователя. И даже если не пихать эту обработку в основной контроллер, то сделать для этой вьюшки своего личного контролерчика.

Это что-то внутри нужно безжалостно давить, или холить и лелеять?

[Котяра]

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