Хорошее MVC

[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. Без всяких событий.

[Psycho Tiger]

Арм... То есть самый главный контроллер, получает команду от коннектора с аргументами и дёргает соответствующие методы у дочерних контроллеров?

Как это реализуется? Динамическим доступом? Был бы очень рад минималистическому примеру :-[

[etc]

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

Арм... То есть самый главный контроллер, получает команду от коннектора с аргументами и дёргает соответствующие методы у дочерних контроллеров?

Как это реализуется? Динамическим доступом? Был бы очень рад минималистическому примеру :-[

Ничего он не дергает, он передает событие с привязанной командой всем желающим. Имя события составное, например command_enterAccount, где enterAccount — имя команды, он же метод основного контроллера (если есть).

[Psycho Tiger]

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

[etc]

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

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

Ещё раз стоит прочитать пост #156, особенно последнее предложение.

[Psycho Tiger]

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

UPD: на всякий спрошу, правильное ли у меня понимание клиентов: клиент - это объект, у которого приходящий запрос может дёрнуть какой-нибудь метод.

[etc]

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

Да, клиентом, здорово. То есть вызываем паблик метод, хорошо.
А как обращаться к коннектору от маленьких контроллеров?

Подписаться на событие типа CommandEvent, у которого будет ссылка на пришедшую команду.

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

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

Можно и так, а можно оформить методом call, в котором первым аргументом идет имя отправляемой на сервер команды. Вариантов полно.