Хорошее MVC

[lammer.Ok]

Спасибо, так и предполагал.
Не поможете ещё с вопросом, допустим есть небольшое приложение-конструктор, которое состоит:

1) Главное меню, содержит кнопку, при помощи которой очищается рабочая область.
2) Рабочая область, где можно создавать квадраты залитые цветом.
3) Тулбар, где есть 2 кнопки "создание" и "удаление" квадрата на рабочей области. Когда нажата любая из кнопок курсором можно создать или выбрать и удалить квадрат, кликнув по нему.

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

1) При загрузке программы Контроллер создаёт Модель и Вьюшку.
2) Вьюшка подготавливает и создаёт внешний вид программы. Устанавливает событие "клик" на кнопку в главном меню и на все кнопки тулбара.
3) Контроллер ловит "клик", когда пользователь нажал на кнопку и определяет, что клик пришёл, допустим с главного меню(или Модель должна определять это?). Записывает в Модели флажок о том, что можно очищать рабочую область.
4) Модель оповещает Вьюшку о изменении в главном меню.
5) Вьюшка проверяет у Модели этот флажок и очищает рабочую область.

Правильно ли я описал до этого пункта?
Далее не знаю как взаимодействовать тулбару и рабочей области. Как например выбрать инструмент "перетаскивания" и передвинуть квадрат. Одно знаю точно у квадрата должна быть своя модель, вьюшка и контроллер? Не подскажите как поступить?

[Dukobpa3]

Всё верно, но пару комментариев.

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

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

Тут может будет для вас что-то интересное:
рас
два

[lammer.Ok]

Спасибо большое. Оказываете неоценимую помощь. Очень интересный этот mvc)
Ещё пару уточнений:

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

2) На сколько я понимаю главная вьюшка создаёт дочерние mv(c) для тулбара и р. области. А вьюшка рабочей области создаёт mv(с) для ректангла?

3) Среди контроллеров может быть прямая связь без подписок между собой?

[Dukobpa3]

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

[lammer.Ok]

Dukobpa3, большое спасибо за ответы, разобрался на данный момент со своими непонятками.

[lammer.Ok]

Появилась небольшая загвоздка в структуре построения дочерних mv.
В этой теме прочитал, что контроллеры создают контроллеры, модели — модели, а вьюшки — вьюшки. Получается, что главные MVC создают основные mvc всего приложения и хранят ссылки на них? Если к примеру, взять тулбар из моего приложения, в главной модели создаётся дочерняя модель тулбара, в главной вьюшке - дочерняя вьюшка тулбара, а в главном контроллере создастся дочерний контроллер тулбара, который свяжет модель и вьюшку тулбара, запросив ссылки на них через родительские MV, типа Model.models.toolbar? В этом собственно и вопрос, правильно ли я понимаю?

[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 минуты
У нас схема простая: бладивский движок с прямой иерархией без отдельных извращений.
Но на самом деле за годы кодинга этого
длинного проекта - вылезли косяки - часто компонент выполняет функции контроллера. ну и фиг с ним - так удобней.