Хорошее MVC

[etc]

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

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

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

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

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

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

[dimarik]

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

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

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

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

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

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

[Psycho Tiger]

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

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

[etc]

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

[Psycho Tiger]

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

[Psycho Tiger]

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

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

[Psycho Tiger]

2) Можно написать отдельный контроллер модели, который работает с соединением и помещает приходящие данные в модель.

dimarik говорит что когда контроллер слушает модель - нонсенс, но ведь не через вьюшку сообщать контроллеру данные от модели...

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

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

[etc]

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

dimarik говорит что когда контроллер слушает модель - нонсенс, но ведь не через вьюшку сообщать контроллеру данные от модели...

Непонятно только, как это относится к указанной цитате.

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

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

Не на коннектор, а на основной контроллер, у которого можно подписаться на события/команды от сервера (они проходят сквозь него после обработки основным контроллером). Коннектор передать нельзя, т. к. клиент у него один — основной контроллер.

[Psycho Tiger]

Непонятно только, как это относится к указанной цитате.

Буфер обмена меня подвёл =)

Контроллер потенциально может слушать модель, т. к. он не единственный контроллер, который может её изменять.

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

Не на коннектор, а на основной контроллер, у которого можно подписаться на события/команды от сервера (они проходят сквозь него после обработки основным контроллером). Коннектор передать нельзя, т. к. клиент у него один — основной контроллер.

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

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

(они проходят сквозь него после обработки основным контроллером) - сквозь что они проходят после обработки основным контроллером? Имеется ввиду конечный слушатель?

Коннектор передать нельзя, т. к. клиент у него один — основной контроллер.

Не совсем понял что ты подразумеваешь под клиентом. Коннектор делается паттерном?
Как вижу я - коннектор после парсинга сообщения и определения принадлежности шлёт событие, если клиент - это слушатель этого события то не вижу преград подписать на него другие классы.

[etc]

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

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

Скорее эта модель более старшая по отношению к контроллеру.

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

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

1) Нет;
2) Парсинг происходит в коннекторе, на выходе получается команда с аргументами;
3) После вызова метода с именем команды, например. Аргументы метода сохраняются для дальнейшей обработки другими контроллерами.

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

Не совсем понял что ты подразумеваешь под клиентом. Коннектор делается паттерном?
Как вижу я - коннектор после парсинга сообщения и определения принадлежности шлёт событие, если клиент - это слушатель этого события то не вижу преград подписать на него другие классы.

На манер LocalConnection#client/NetConnection#client. Без всяких событий.