загрузчик в MVC || S

[Babylon]

Возможно и я когда-нибудь перейду на сигналы.

[Psycho Tiger]

Интересная тема! Из неё я подчерпнул, что Babylon явно что-то дует.

У меня вот дерзкие мысли:
1) Модель имеет бизнес данные приложения. Степень абстракции сформулировать трудно, но её вполне можно чувствовать.
2) Вью полностью верит модели и отображает всё согласно ей.
3) Модель вполне сама может решить, что ей кэшировать (например, ресурсы на карте), а что спрашивать у сервера.

Отсюда я заключаю, что контроллер не нужен. Это лишний код, лишние связи. KISS and DRY!

А ещё есть классный принцип "we are all adults here". Это когда код пахнет розами, в нём нет шизофренических проверок "от дурака" и дураков к нему не допускают. А если кто-то делает глупость и всё ломается... Ну ничего, починим. Мы же здесь все взрослые. Мы пишем тесты.

[Babylon]

Я уж лучше с контроллером останусь и буду дальше "дуть".

[Котейка]

У меня вот дерзкие мысли:
1) Модель имеет бизнес данные приложения. Степень абстракции сформулировать трудно, но её вполне можно чувствовать.
2) Вью полностью верит модели и отображает всё согласно ей.
3) Модель вполне сама может решить, что ей кэшировать (например, ресурсы на карте), а что спрашивать у сервера.

Отсюда я заключаю, что контроллер не нужен.

Ай хитрите В вашей схеме контроллер и не нужен верно, или, если сказать точнее, можно без него обойтись. Добавьте в нее действия пользователя и понадобится контроллер

[Psycho Tiger]

Вью может сама обработать действия пользователей. Это проще и логичней, чем гнать это в контроллер.

[Котейка]

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

[Dukobpa3]

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

контроллер не нужен.

Вцелом как-то так. В последнем своем варианте я пришел к архитектуре с медиатором.
В итоге получается примерно следующее:
- есть обсервер. Через него общаются контроллеры. Можно сказать что то, что не попало в обсервер - не попадет на сервер.
- модель, собственно модель, логика в ней. При изменениях диспатчит события.
- вью тупая, слушает модель, рисуется согласно тому что в модели, диспатчит клики и прочее наружу.
- Медиатор умеет спамить в обсервер, но не умеет слушать. В медиаторе нет ссылок на модели. Медиатор слушает вьюхи, но не содержит логики. Может клик из вьюхи отправить на сервер, если это не требует логики, а просто отправки.
- Контроллер содержит ссылки на модели. Контроллер умеет спамить в обсервер и слушать из него. Контроллер слушает вьюхи, контроллер дергает какие-то паблик методы модели, просит ее обновиться, содержит какую-то логику, но не математику. Контроллер нужен там, где происходит НЕЧТО, которое выбивается из общей системы.

Есть пачка моделей, по назначению. Профиль игрока, лобби, статик данные.
Есть пачка вьюх, опять же по назначению. Окна, екраны, попапы.
Есть несколько медиаторов, один медиатор обслуживает однотипные вьюхи - медиатор попапов, медиатор окон, медиатор скринов.
Есть несколько контроллеров. Контроллер тутора, контроллер квестов, контроллер ГГ.

Вцелом небольшое приложение может обойтись одним контроллером, одним медиатором, одной моделью и тремя-пятью вью.

[Wolsh]

Я бы, наверное, обобщил так, что контроллер может содержать ту логику, для которой ему не нужны данные из модели (если такая бывает). Впрочем, и тут некоторые хитрят и заставляют Вью брать у модели нужные данные и только потом дергать контроллер, отдавая эти данные ему)). В целом же контроллер должен заниматься потоками и в некоторых случаях интерпретацией (переводом в нужный формат) данных, но не их логической обработкой (как, например, рассчетом столкновений).
Помещение логики в модель как раз и позволяет отказаться от тысячи открытых геттеров данных — [промежуточные] данные обрабатываются там же, где и хранятся, а отдаются только конечные результаты.

Добавлено через 17 минут
Обычно подразумевается, что Модель очень сложна и Вью очень сложна, и лучше их не трогать, если есть возможность. Контроллеров же может быть сколько угодно, они могут быть спортивными и легко изменяемыми. Их задача — сделать возможными любовные отношения между Вью и Моделью даже тогда, когда Вью берется из одного проекта, а Модель — из другого. В такой ситуации, конечно, допустимо и события из Модели ловить специальным контроллером и передиспатчивать их для Вью в том формате, под который написана Вью. Но это, конечно, нечастая ситуация)) Однако, она наглядно показывает роль контроллера вообще. Его роль — знать, какие действия из Вьюхи каким образом должны "менять" Модель. Точно так же, как любой [электронный] контроллер устройства преобразует некие физические события (замыкание/размыкание клавиши) в программные события, понятные Системе.

[Babylon]

...для выполнения команд контроллером.