Хорошее MVC

[etc]

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

В этой теме затронут вопрос, с которым я давно не могу разобраться: как же все-таки делать иерархию mvc?

Из вышесказанного я смог выделить несколько мыслей:
1. Модель у нас одна, все слушают её и пишут в неё.
2. Иерархия модели аналогична иерархии DisplayList'а.

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

У нас второй вариант. И контроллеры тоже ветвятся, но не как DisplayObject, а простой связью — более старший контроллер передает ссылку на себя младшему. Как правило, в конструкторе.

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

Допустим, есть игровое приложение, состоящее из двух больших кусков: "курилка", где можно создать игру либо присоединиться к существующей, и собственно сама игра.
Document Class создает главный контроллер и передает ему ссылку на себя же в качестве контейнера, этот контроллер создает модель, затем создает вид, передавая ему модель, и добавляет в контейнер. Главная триада up and running.
Теперь нужно добавить триаду, которая будет отвечать за курилку. Как это должно произойти? Как она должна быть связана с главной триадой?

Основной контроллер грохнет вид, контроллер и модель игры, создаст модель курилки (если она не живет с самого начала) и вид с контроллером курилки. Проще говоря, создает другую триаду. Основная триада максимум получает пользовательские события от дочерней. В случае, если игра оффлайн, то получает событие «Игра закончена», либо в случае онлайна — от сервера.

Добавлено через 3 минуты

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

Спасибо, вроде прояснилось.
Еще вопрос: каким образом из дочерней триады достучаться до родительской модели?

Я вот честно говоря совсем не вижу необходимости. Зачем оно? Как максимум, к родительской модели может обратится дочерний контроллер через ссылку у родительского контроллера.

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

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

Значит где-то нет проверки на текущее значение.

[Psycho Tiger]

Основной контроллер грохнет вид, контроллер и модель игры, создаст модель курилки (если она не живет с самого начала) и вид с контроллером курилки. Проще говоря, создает другую триаду. Основная триада максимум получает пользовательские события от дочерней. В случае, если игра оффлайн, то получает событие «Игра закончена», либо в случае онлайна — от сервера.

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

[etc]

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

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

Да, я это и предлагаю.

[Psycho Tiger]

Мне не совсем понятно, откуда главный контроллер получает уведомления от дочерних. По той ссылке, что передается в конструктор?

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

[etc]

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

Мне не совсем понятно, откуда главный контроллер получает уведомления от дочерних. По той ссылке, что передается в конструктор?

Подпишется на события дочернего.

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

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

Вообще-то должно быть наоборот. Менять или не менять режим игры — решает главный контроллер на основании, скажем, дочернего контроллера, но никак не модели. Можно и от модели, конечно, но не по событию «Сменить режим».

[Psycho Tiger]

Мм. У меня в главной модели есть свойство currentGame, например.
Дочерний контроллер решает, что он сворачивается, и меняет свою модель. Эта модель изменяясь сообщает модели выше (главной) что всё свернулось, и меняется currentGame (например, на "menu"). Главный контроллер слышит это и решает, что делать дальше. Чаще всего добавляет меню )

Чем такой подход плох?

[etc]

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

[Psycho Tiger]

М, ну да, прав. Поэтому в принципе поток инфы через модель излишнее, спасибо.

[dimarik]

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

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

У нас модель стала общаться с контроллером? Это нонсенс.

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

Правда, я разок сделал по-своему. Если модель не имела значения для определенной переменной, то диспатчила об этом событие. Событие подхватывал контроллер и говорил "Ах, %model_name%, у тебя нет того, что у тебя просят. Ща забацаем." Удобство было в том, что вьюхи, созданные в некотором количестве инициировали чтение геттера модели. Геттер им отвечал дефолтно и попутно сообщал контроллеру и том, что нужно бы сделать так, чтобы у меня появились чисто конкретные данные, on demand, как бе. Весь цинус в том, что пока вью реально не попросит, не нужно напрягать сетевые ресурсы качать мегабайты.

Вот. А реально я ничего нового не придумал. Этот паттерн умные GoFы давно придумали и назвали Proxy. Вспомни я про это, то сразу бы избавил модель от ненужной суеты.

[Psycho Tiger]

Понятно, поучительно, спасибо)

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