Хорошее MVC

[lammer.Ok]

Есть здесь кто живой? %)

[in4core]

А тебе зачем?

[ShockWave512]

Флеши меняются, а хороший MVC остается на века!

[lammer.Ok]

Кто-нибудь помогите решить заморочку).
Я пишу средне-небольшой графический редактор, используя ест-но парадигму MVC. Спроектировал основную часть редактора и настал черед реализации графических инструментов. Так вот, начал я с инструмента "Линейка". Вид и функционал её прост: имеются 2 стрелки на обоих концах, которые можно тянуть в разные стороны и при этом считается длина от одного конца к другому, также её можно поворачивать на 90 градусов. Линеек в редакторе можно создавать бесконечное множество.

Ближе к заморочке.
Следуя MVC, я создал Модель, Контроллер и Вьюшку для данного инструмента. Вьюшка сообщает Контроллеру о том, что линейку тянут. Контроллер получает координаты конца линейки и говорит Модели просчитать новые координаты кончиков стрелок линейки, а также посчитать длину от одного конца к другому. Модель всё просчитывает и диспатчит событие об изменении. Вьюшка ловит событие от Модели, берёт у неё данные и рисует.
Как мы видим обязанности строго разделены между MVC. Модель содержит логику и данные, Вьюшка только отображает, а Контроллер руководит процессом.
Всё было бы хорошо, если бы меня не посетила мысль, а не слишком ли так заморачиваться и забивать память приложения хранением MVC для каждого экземпляра Линейки, да ещё и для такого мелкого инструмента, и, вообще есть ли смысл разделять на триаду данный инструмент. А также при событии движения мыши получается куча всплытий событий от вьюхи, контроллера и модели. Почему бы не превратить все это в MV, где Вьюшка возьмёт на себя роль контроллера и часть математических расчётов. Но тогда я получу не очень красивый код и разрушу идею канонического MVC.
Помогите кто-нить советом. Где я упоролся в данной случае?

[ShockWave512]

2 lammer.Ok
- mvc - это уровень архитектуры приложения, тащить его в реализацию рендера единственной вьюхи не стоит
- вью тут достаточно для холста и панели инструментов, меню
- я бы сделал модель холста, и в ней бы хранил все линейки (в том числе), а обновлятся модель будет и так на каждый тык
- линейка простой класс, отрисовщик и дизайнер (который слушает клики на линейке и таскает её), дизайнер диспатчит сигналы-ивенты о изменениях в вью/медиатор (как и все остальные инструменты)

[lammer.Ok]

- mvc - это уровень архитектуры приложения, тащить его в реализацию рендера единственной вьюхи не стоит

Почему не стоит? Это же удобно. Например, у меня модель всей сцены хранит модели всех инструментов отображенных вьюшкой сцены. Когда пользователь хочет сохранить рисунок, все модели сериализуются в один xml или json-объект и загружаются на сервер. Когда хочет загрузить рисунок, то опять же, xml парсится, фабрики создают модели и вьюшки, а контроллер сцены выдаёт контроллер инструмента, который будет связывать все MV инструмента. Вьюшка сцены хранит все вьюшки инструментов, она слушает дополнительно дочерние вьюшки и контролирует частоту перерисовки. При запросе удаления инструмента удаляется его модель и вьюшка. Как по мне так достаточно удобно использовать MVC и для инструментов. К тому же в данной теме также советуется использовать MVC и для часто рисующихся объектов.

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

Эту часть я не совсем понял. То есть, получается у нас есть класс "Линейка", который сам себя считает и рисует. Когда мы хотим удалить линейку со сцены, то, к примеру, медиатор, связывающий вьюшку холста и все инструменты кричит вьюшке холста удалить тек. экземпляр линейки из ёё коллекции ? Так ?

[ShockWave512]

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

- mvc это технология отделения данных от представления и еще на ней бюрократизация приложения, разложение по полочкам и папкам разных структурных элементов, в mvc это разделение решает взаимосвязь данных и их представление на клиенте. Это как уголовные дела по папкам в участке, дело = папка, но никому не приходит в голову заводить папку/дело на каждого участника инцидента.

- неважно сколько рисуется в секунду объект, или сколько раз на экране, это глупо лепить медатор к кружочкам или квадратикам, даже если их сотни на холсте!

- технически вью говорит что выбран допустим объект на холсте, медиатор или модель помечает текщим, а его удаление или еще какая команда обычно приходит из другой связки медиатор/вью где сидит кнопка удаления или еще какой элемент управления, модель удаляет объект -> кричит всем что данные сменились, вью холста ловит это и обновляет холст

(пысы: в этой теме можно писать тонны текста, прям кладезь для демагогов)

[lammer.Ok]

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

Зачем для всех? Один медиатор для всех и отдельная вьюшка для каждого. Но согласен, это избыточно и соб-но по-этому обратился на форум.

- mvc это технология отделения данных от представления и еще на ней бюрократизация приложения, разложение по полочкам и папкам разных структурных элементов, в mvc это разделение решает взаимосвязь данных и их представление на клиенте. Это как уголовные дела по папкам в участке, дело = папка, но никому не приходит в голову заводить папку/дело на каждого участника инцидента.

Понял. Видимо я слишком зациклился на парадигме, минуя логику принципа.

- неважно сколько рисуется в секунду объект, или сколько раз на экране, это глупо лепить медатор к кружочкам или квадратикам, даже если их сотни на холсте!

- технически вью говорит что выбран допустим объект на холсте, медиатор или модель помечает текщим, а его удаление или еще какая команда обычно приходит из другой связки медиатор/вью где сидит кнопка удаления или еще какой элемент управления, модель удаляет объект -> кричит всем что данные сменились, вью холста ловит это и обновляет холст

Всё вроде бы выглядит логично, но почему событие удаления объекта не приходит в контроллер сцены и он не сообщает модели удалить объект?

[ShockWave512]

Сообщение от lammer.Ok

Всё вроде бы выглядит логично, но почему событие удаления объекта не приходит в контроллер сцены и он не сообщает модели удалить объект?

да через контроллер правильно
это я привык мухлевать напрямую в модель, а контроллеры использую только для важных моментов приложения (загрузка, запуск главного вида, сохранение/загрузка)

[lammer.Ok]

Понял. Ну тогда всё очень даже логично вырисовывается + мне легко внедрить изменения структуры в приложение. Ещё хотел уточнить, у меня данные о линейке(размер, угол) и о всех других инструментах будут ещё выводиться в дополнительном информационном окне и неудобно без прослушивания модели инструмента отдавать данные в это окно. Можете что-то посоветовать?