Хорошее MVC

[Dukobpa3]

Кроме этого варианта в этой же теме еще пачка других есть.
Лучше посмотрите известные фреймворки и как там это разруливается.
Везде по-разному, и тут вопрос в том как вам больше нравится. Одного "правильного" решения нету.

Описание паттерна мвц вообще не выходит за рамки одной триады одного модуля.
А как эти небольшие триадки между собой увязать - большое поле для творчества.

[lammer.Ok]

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

[Dukobpa3]

Могу своими решениями поделиться разве что.

Изначально было следующим образом:
0. В каждом контроллере есть ссылка на хост, т.е. контейнер, в который он ложит свои вьюхи.
1. Каждый контроллер сам создает свои вью и модели.
3. Есть главный контроллер, в который в качестве хоста передается ссылка на мейн, либо на одного из чилдов мейна. Этот контроллер пихает в свой хост другие контейнеры-спрайты, которые раздает другим контроллерам.
4. Контроллеры в два уровня - главный, и в нем все остальные инитятся. Таким образом главный контроллер как инициализатор всего приложения, он создает остальные контроллеры, они в свою очередь создают свои вью-модели.
5. Общение между контроллерами происходит через главный контроллер, контроллеры диспатчат в него, он там разруливает эти нотификации. Т.е. главный контроллер выступает в роли медиатора для остальных контроллеров.

Плюсы:
- четкое дерево зависимостей.
- каждый модуль системы по сути является контроллером. Сколько контроллеров - столько модулей. Легко отключать включать модули целиком, просто закомментировав создание контроллера.

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

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

Плюсы:
- таким образом я оторвал создание вью и модели от контроллера и по сути решил вопрос с доступом разных контроллеров к одной вью
- так же решился и доступ разных контроллеров к одной модели
- так же несколько вью могут быть подписаны на одну модель.

Минусы:
- Увеличилась связанность.
- Сложнее идентифицировать отдельный "модуль", хотя, по прежнему можно отталкиваться от понятия модуль == контроллер. В некоторых ситуациях это не конает но по большей части ок.


Все другие мои варианты являются производной от первого либо второго варианта.

1. Я делал более жесткое дерево контроллеров, моделей и вьюх. Не два уровня главная-остальные, а именно полноценное дерево всей системы, со всеми вытекающими.

Плюсы:
- Когда вся система собрана и связи между классами налажены, ссылки кому надо переданы - дерево вьюх и дерево моделей становятся хзеркальными по отношению друг к другу, таким образом легко связать самую маленькую модельку кнопочки с самой маленькой вьюшкой кнопочки, на каком бы уровне они не находились. Благодаря этому получаем очень удобный рендер.

Минусы:
- Стало сложнее всю систему собрать и єти саміе ссілки из раздела "плюсы" раскидать куда надо. В инициализации стало больше кода.

2. Я делал какие-то статик манагеры вьюх и моделей. Для общения между контроллерами сделал обсервер.
Плюсы:
- Если не брать в учет инициализатор - связанность в таком проекте очень низкая, могу отключить любую вью, модель или контроллер и ничего не отломается.

Минусы:
- всё инитится в инициализаторе Так что пункт про связанность спорный (получается что отключить одну модель от системы легко, а вот запустить только одну модель - уже проблематично). Тесты писать становится неудобно. Проинитить одну модель не проинитив всё приложение - практически нереально.


//**************************
Как-то так.
По сути больше и вариантов то нет.

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

[inject]
var model:DesignModel;

То же самое что и:

var model:DesignModel = ModelManager.getModel(ModelsList.DESIGN_MODEL) as DesignModel;

Просто с манагером весь код видно, даже код из манагера, а с IoC контейнером он спрятан в фреймворке контейнера.

//*************************
Во многих вариантах отказываются от контроллеров в пользу команд. Тут очень спорно и очень зависит от реализации. Например как это реализовано в PureMVC - тонуевонафиг.
Реализация Robotlegs более удобна, но чисто мое субьективное мнение - удобнее с контроллером.

[Котяра]

надо просто не упарваться и просто писать код.

Добавлено через 4 минуты
У нас схема простая: бладивский движок с прямой иерархией без отдельных извращений.
Но на самом деле за годы кодинга этого
длинного проекта - вылезли косяки - часто компонент выполняет функции контроллера. ну и фиг с ним - так удобней.

[Akopalipsis]

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

[caseyryan]

то получается, что вью ещё не создана и отображать некому.

Так в чем проблема создать-то?

[Akopalipsis]

Так в чем проблема создать-то?

Проблема, которую я надеюсь Вы поможете решить, в построении логики.
Мысли на этот момент у меня вот какие - сначала о первом запуске приложения:
Выполнился Main и создал класс конфигурации приложения, где и создаются модель, вью, контроллер и получают настройки менеджеры. В один из этих менеджеров входит и ассет менеджер, в задачу которого входит создавать загрузчики и забирая контент, складывать его в фабрики. От сюда выходит, что первым должен инится ассет менеджер, так-как после создания mvc, все пойдет своим ходом и все вью получат ссылки на свои do из фабрик, а модели получит ссылки на vo. Но при таком раскладе вью не сможет отображать прогресс, так-как ещё не создана.

Мои мысли о запуске ассет менеджера после создания mvc:
Первым о чем хочется сказать, я не знаю, как вью, даже в первом случае, получит ссылку на прогресс.
Но я опущу это и продолжу, создаются mvc и не чего не происходит, потому что они ещё не наполнены,
потом я запускаю загрузку и после завершения мне нужно у каждого класса mvc вызвать метод init.
Но это уже криво... И так же, как и в первом случае, я не знаю, как вью получит ссылку на прогресс.

И ещё вот какой момент я не понимаю. Есть задача в запущенном приложении, грузить фото. Запускается сценарий загрузки и ассет менеджер создает столько загрузчиков, скольно нужно загрузить фото. От сюда вопрос - как вью получить ссылки на все эти загрузчики, чтобы для каждого создать вью-прогресса загрузки?

[Dukobpa3]

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

Весь форум уже вкурсе что у вас, юный падаван, проблемы с логикой
*trollface.jpg*

Чтобы вью знала прогрресс - ассет-манагер должен каким-то образом об этом прогрессе сообщать. Собственно для ответа на ваш вопрос - этого достаточно.

Более развернуто:
1. Есть некий глобальный прелоадер который инитится после инициализации ассетманагера, но до старта загрузки.
2. Этот прелоадер показывает прогресс каких-то основных ассетов. Тут важно найти баланс, потому что весь арт засунуть в этот прелоадер - отложите запуск приложения на неопределенное время. А в играх загрузка более 10 сек - не ок.
3. Далее ассет манагер либо фабрика должна выдать либо ссылку на лоадер либо иной интерфейс чтоб любая вьюха могла получить ссылку на нечто, которое можно сразу добавить на сцену либо же дождаться пока оно материализуется и желательно посчитать проценты.

Как-то так.

Добавлено через 30 секунд
И к мвц это вроде не относится.

[Akopalipsis]

Чтобы вью знала прогрресс - ассет-манагер должен каким-то образом об этом прогрессе сообщать.

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

[Dukobpa3]

Ассеты и лоадеры это не данные.
Даннные это например номер_ид текста. А по этому номеру берется текст из локализации.
Или так же какой-то ид ассета, а по иду берется урл из манагера либо же ассет из фабрики.

В модели ассетов НЕТ.