PDA

Просмотр полной версии : Хорошее MVC


Страницы : 1 2 [3]

TanaTiX
09.11.2012, 02:23
Я вот тут подумал, а правомерно ли говорить об MVC во флеш-проектах в полной мере? Думаю, что реально в проектах используется не 3, а 4 элемента:
1) Модель - ее предназначение дискутабельно в рамках данной темы, но данные она все же хранит
2) Вью - то, что рисует дизайнер в ИДЕ (да, именно такая структура бывает далеко не всегда, но, думаю, достаточно часто), а мы, к примеру, подключаем это в виде класса, который дергаем из swc.
3) Контроллер, который, по сути, является тоже вьюхой и одновременно контейнером для вью (п.2) - там как раз и происходит подписка на слушатели различных элементов и пр.
4) Собственно контроллер - один большой и важный, который содержит в себе глобальную логику, на мелочи не разменивается, к примеру, управляет состояниями приложения.

И есть одна вещь у тигры, с которой, думаю, никто спорить не будет - у каждого мвц свой. Кстати, в том же вики об этом упоминается, что для реализации мвц могут быть применены разные паттерны. Частично в этом (выбор реализации) нам помогает идеология as и флеша.

ЗЫ. туалет и ванная - потрясающие помещения: столько мыслей приходит.

Добавлено через 1 минуту
Dukobpa3, на счет переписывания вики - почитай историю. Там примерно одно и тоже. Правда я раньше некоторые моменты пропускал мимо :(

Dukobpa3
09.11.2012, 02:29
В общем, вам в раздел: "наиболее частые ошибки"
Вики мвц (http://ru.wikipedia.org/wiki/Model-View-Controller)

TanaTiX
09.11.2012, 02:43
Dukobpa3, читал я этот раздел. Могу конечно ошибаться, но почему-то мне кажется, что та статья не учитывает специфику флеша. А может это и сила привычке во мне говорит. Вообще надо как-нибудь задуматься, чем плох/хорош используемый мной подход (в т.ч. и сам паттерн), чего бы хотелось и, соответственно, как это все реализовать.

Sintesis
09.11.2012, 03:02
По той статье всё что здесь писали не правильно.

Dukobpa3
09.11.2012, 03:08
а ты прочел всё что здесь писали?)))))

Sintesis
09.11.2012, 03:26
Переубедил, хотя не ты а Википедия, да то что писал ПсихоТайгер не сходится с классическим активным MVC. Контроллер реализует только интерфейс с пользователем - ввод с клавиатуры и ввод с вьюшки, таким образом только соединяет модель и представление, в одну сторону от вьюшки в модель, модель всё решает, что делать с этим вводом и результат отдаёт в вьюпорт.
Понятно всё, почему-то в голову приходят сразу такие программы как Фотошоп, например всё что мы видим - делал один отдел программистов, а всё, чем думает программа - другой отдел, потом это соединили контроллером.
Зачем в начале темы так тщательно описан не правильный подход с пассивной моделью?

Dukobpa3
09.11.2012, 03:56
Зачем в начале темы так тщательно описан не правильный подход с пассивной моделью?
у тигры спроси

Добавлено через 30 секунд
хотя не ты а Википедия
Я там выше говорил, не за что ;)

Sintesis
09.11.2012, 04:04
Я там выше говорил, не за что ;)
Ты не убедил из-за того что сам путался
http://flasher.ru/forum/showpost.php?p=1103555&postcount=490

Dukobpa3
09.11.2012, 04:06
Цели убеждать нету как бы. Ты спросил я ответил)

Sintesis
09.11.2012, 04:09
Но спасибо всё равно, а то не правильным путём пошёл-бы.

Добавлено через 14 минут
Dukobpa3, читал я этот раздел. Могу конечно ошибаться, но почему-то мне кажется, что та статья не учитывает специфику флеша.
Что-то и мне так кажется, в силу того, что у нас есть такие высокоуровневые классы как Sprite где и View и кусок Controller'а уже вроде как реализованы. Спрайт-то и отображаться может и события рассылать, осталось только модель добавить. Может по этому в начале поста выдумывают всякое?

TanaTiX
09.11.2012, 04:31
Sintesis, не стоит относиться к этому посту, как к непреложной истине. Тигра старался как мог, но все мы люди: можем ошибаться, и на всех не угодишь. Но те статьи, что он написал были рождены не одной темой на форуме или статьей на вики. Даже если делать не так, то прочитать, думаю, стоило бы однозначно. Мне вот все покоя дубовый стол не дает :)

Dukobpa3
09.11.2012, 15:14
Что-то и мне так кажется, в силу того, что у нас есть такие высокоуровневые классы как Sprite где и View и кусок Controller'а уже вроде как реализованы. Спрайт-то и отображаться может и события рассылать, осталось только модель добавить. Может по этому в начале поста выдумывают всякое?
Нужно учитывать что могут быть всякие композиции типа:
MV-C (Модель и вью в одном классе)
MC-V (модель с контроллером в одном классе)
M-CV (Вью с контроллером в одном классе)

И в таком духе.

Добавлено через 1 минуту
Я там выше говорил: главное четко для себя осознать роль каждого из составляющих М, В, Ц.
А там уже можно делать как больше нравится, главное чтоб самое суть оставалась.

Sintesis
09.11.2012, 19:42
Я к тому, что создавая проект в флеш девелоп например - точку входа наследуем от Спрайт и она автоматически у нас становится VC так как наследует и дисплай обжект и ивент диспетчер.

Dukobpa3
09.11.2012, 19:46
Диспатч ивента это одельная муть совсем. Каким иначе образом ты подпишешься контроллером на вью. А эта подписка предусмотрена в "академической" модели мвц.

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

У меня вообще контроллеры общаются посредством своего обсервера. Совсем отдельно от событий.

Добавлено через 39 секунд
С таким же понтом можно сказать что и модель тоже контроллер, она же как-то диспатчит вьюхе об изменениях.
Но это будет неверная формулировка.

Sintesis
09.11.2012, 22:42
В вьюхе не должно быть условий if? Это к логике относится?

Dukobpa3
09.11.2012, 22:56
Я вопроса не понимаю.
Это просто условие.

например:
if(model.locked) drawLock();
else drawUnlock();

Sintesis
09.11.2012, 23:04
Я вопроса не понимаю.
Это просто условие.

Ну говорят, что вьюха тупая, а if(){} это уже подумать нужно: "если так - то сделаю это, если не так - то не буду этого делать"

Dukobpa3
09.11.2012, 23:28
Вьюха может содержать логику касающуюся отрисовки.
Вьюха не может содержать логику касающуюся математики.

Разница в том что в первом случае от решения вьюхи никого кроме нее не зацепит
Во втором - от решения будет зависеть какая-то цифра которая повлечет за собой последствия.

О таких вещах очень сложно говорить без примеров. Давай конкретные вопросы, а то это всё больше начинает напоминать демагогию.

Sintesis
09.11.2012, 23:49
Ага, спасибо, это нужно знать!
Пример такой: вьюшке нужно узнавать на каком этапе сейчас приложение, например если в модели стоит startMenu:Boolean = true; то она отобразит нужные кнопки и нужную графику. Значит можно сделать в вьюшке так:
if (_model.startMenu) {
this.removeChildren();
this.addChild(_BGMenu);
this.addChild(_startButt);
...
}

Dukobpa3
09.11.2012, 23:57
Прочти наконец-то тему сначала и до конца!!!
Я это уже раз третий так точно тут же объясняю....

Sintesis
10.11.2012, 00:02
50 страниц(, я до 25 дочитал и уже каша в голове, каждый свою ситуацию разбирает, а в начале темы вообще всё не правильно, уточнить хочется раз и навсегда... Да и я тебе плюсиков понаставлю)))

Dukobpa3
10.11.2012, 00:06
Ну блин. Я понимаю. Я просто тоже не дятел одно и то же долбить))
Дуй в личку если что, там скайп мой тоже есть.

Akopalipsis
07.08.2013, 12:42
Читал два дня, очень интересно и познавательно, но некоторые моменты я хочу уточнить.
Меня больше всего интересует вот это:
поэтому спрашиваю, контроллер(предположим игры) создает контроллер игрока, уровня и врага. Контроллер игрока в свою очередь создает модель игрока и вьюшку игрока, с уровнем и врагом
Контроллер игрока модель игрока не создает.
А кто тогда создаёт? И хочется спросить тех кто начинал эту тему - у Вас за время прошедшее с момента написания, поменялось представление или вы остались при своих мнениях?

Zebestov
07.08.2013, 12:51
Контроллеры создают контроллеры, модели — модели, а отображения — отображения.

etc
07.08.2013, 12:57
А кто тогда создаёт? И хочется спросить тех кто начинал эту тему - у Вас за время прошедшее с момента написания, поменялось представление или вы остались при своих мнениях?

Модель же и создаёт при десериализации пришедших данных.
Мнение не изменилось.

Akopalipsis
07.08.2013, 13:15
Zebestov Спасибо! И ещё вопрос - субклассы наследуются от главных классов или не обязательно?
etc Спасибо!

Zebestov
07.08.2013, 13:38
Лично у меня нет "ядра" MVC, контроллеры и модели наследуются от EventDispatcher, отображения — от соответствующего наследника DisplayObject. В моих приложениях MVC — это просто правила построения, никакого "костяка" или фреймворка.

Babylon
07.08.2013, 13:53
А лично у меня есть ядро, от которого наследуются модель, контроллер и вид. Кроме этого есть глобальный диспатчер, который наследуется от EventDispatcher и работающий с соответствующими ссылками.
Есть Еngine который выполняет команды. Loader который грузит XML со всем: c иерархией видов , параметрами модели, командами, хэндлерами, коллекциями виджетов, сервисов и настроек.
Вид имеет интерфейс с виджетами, модель с сервисами. Все дела.

Zebestov
07.08.2013, 14:15
Тоже вариант. В моих приложениях такая степень абстракции просто неуместна, на мой взгляд.

Akopalipsis
11.08.2013, 19:00
Хочу уточнить вот что - если модель создает модели, вью создаёт вью, как тогда вью узнает о своей модели?

Zebestov
11.08.2013, 19:07
Контроллер передает в конструкторе.

Dukobpa3
11.08.2013, 20:13
Как вариант, да и впринципе практически всегда конает.
Но вообще вью может быть подписана не на одну модель.

Т.е. модели к примеру:
- профиль игрока
- текущий бой
- статические данные (ссылки на арт, конфиги и прочую муть)

А вью к примеру - магазин. Подписывается и читает профиль плюс статические данные.
Вью боевки - читает профиль и модель боя.

Добавлено через 5 минут
Я после того как инкапсулировал логику в моделях - перестал комплексовать на тему дробления моделей, вплоть до того что могу на весь проект тупо две модели сделать: Статик данные(конфиги игры, цены в магазине, ссылки на ассеты) и динамик данные(то что меняется во время игры, текущее состояние карманов игрока и в таком духе).

Так как у модели всего парочка паблик методов которые что-то могут изменить - то накосячить очень сложно.
А то что одну модель смогут читать все кому не лень - ну и пофиг. Упрощает жизнь.

Akopalipsis
11.08.2013, 21:10
Но вообще вью может быть подписана не на одну модель.
я вот как тренируюсь - контроллер создаёт модель и передаёт её во вью. Все как по стандарту.
Вью по умолчанию создаёт круг и считывает цвет у модели. В модели через несколько секунд срабатывает таймер, который говорит ей, что нужно создать другую модель, модель квадрата. Она успешно создает модель квадрата и диспатчит вью, что уже можно рисовать квадрат и считывать с него цвет, так как модель квадрата создана. Вью рисует квадрат, но вью квадрата не чего не знает о модели квадрата. Где у меня хромота начинается?

Dukobpa3
11.08.2013, 21:14
Ну большая вью например может передать модель вьюшке квадрата, так же как контроллер сделал с ней.

Akopalipsis
11.08.2013, 21:28
Dukobpa3 Спасибо вам за вправку мозга! я что с миниатюрами забыл, что смена модели это куда больше чем цвет)))

Akopalipsis
17.08.2013, 18:28
Вроде банальный вопрос, но я лучше уточню - кто слушает стайдж, когда по её ресайзу должны меняться данные в модели?

Dukobpa3
17.08.2013, 19:16
Не знаю как у кого, но у меня есть небольшая модель конфига игры. В ней размеры(екрана, поля боя), позиционирование, всякая псевдоигровая доп-лабуда типа флешваров и прочего.

На стейдж подписан Мейн. Стартовый класс игры. По изменению размеров стейджа - меняет содержимое конфига.А далее уже все заинтересованные лица подписываются на него(Часто он у меня просто статический класс, так что никто не подписывается, просто знают что в нем всегда актуальная информация).

Akopalipsis
19.08.2013, 21:33
Dukobpa3 Спасибо! я пока склоняюсь к двум вариантам - либо в контроллере ( так как у него у одного может оказаться ссылка на стейдж ), либо в контроллере сделать статическую ссылку и слушать в модели ( так как все равно по ресайзу происходит перерасчёт в и передается во вью ).
Вариант с конфигом пока не рассматриваю, но точно знаю что придётся, так как фреймворки этого требуют.
оффтоп. если кто то может помочь в вопросе - какое место занимает Старлинг в MVC, жду Вас в этой теме http://www.flasher.ru/forum/showthread.php?t=202824&page=2

Добавлено через 48 часов 11 минут
Перед написанием этого вопроса, прочел ещё раз посты которые формировали моё сознание)))) И нашёл то, что ещё не спрашивалось - контроллер слушает модель?) Он может быть подписан на события в модели?

Dukobpa3
19.08.2013, 22:02
Может. Но идею это нарушит.

Akopalipsis
19.08.2013, 22:24
Вправьте мне мысли
Запуск приложения
Main отдает ссылку на отображение контроллеру
Контроллер создаёт модель ( в конструкторе происходят подготовления )
Контроллер создаёт вью и кидает ей ссылку на модель ( в конструкторе вью происходят подготовления )
Контроллер создает контроллерСервис и в конструктор кидает ссылку на модель
Контроллер сервис в конструкторе создает Сервис

Кто должен предпринимать действия по запуску загрузки?
я просто думал что если логика в модели, то модель должна хранить значение "первого запуска" и говорить контроллеру, чтобы сервис грузил. Тогда как получается, контроллер решает о первом запуске или сервис?

Dukobpa3
19.08.2013, 22:54
Сделай хоть как-то, покажи что получилось, тебе укажут ошибки. А демагогия лично меня уже достала чуток.

Akopalipsis
19.08.2013, 23:26
ЗДЕСЬ БЫЛ КОД, КОТОРЫЙ РУГАЮТ НА ЭТОЙ СТРАНИЦЫ, В ПЛОТЬ ДО СЛЕДУЮЩЕГО МОЕГО СООБЩЕНИЯ.)
ЧТОБЫ НЕ ЗАСОРЯТЬ РАЗУМ ТЕМ, КТО ЧИТАЕТ ЭТУ ТЕМУ, Я ЕГО УДАЛЯЮ.

in4core
30.08.2013, 21:17
Akopalipsis - откуда вообще весь этот код? Вы его сами написали? У вас совершенно нет понятия о том, что должно быть и как с этим работать. Попробуйте сначала изучить самый самый, повторюсь САМЫЙ - стандартный MVC - в блогах у Psycho например есть реализация такового. Изучите, попробуйте написать приложение, какое нибудь простое, а потом сами начнете понимать о чем речь и какие проблемы возникают.
Сейчас я вижу MainController($doc:DisplayObjectContainer,$stage:Stage) После чего обычно направляют читать книги по AS3 и ООП. Дабы не мучать вас догадками почему? Отвечу : $doc ваш это хост, ссылка на root обычно ( main класс ) , который уже добавлен на Stage. Догадались почему второй параметр стейдж это убого?!

Psycho Tiger
31.08.2013, 13:53
Дабы не мучать вас догадками почему? Отвечу : $doc ваш это хост, ссылка на root обычно ( main класс ) , который уже добавлен на Stage. Догадались почему второй параметр стейдж это убого?!
Отлично! А теперь дядюшка Артём расскажет, почему ты можешь быть не прав:

Я процитирую:
$doc ваш это хост, ссылка на root обычно который уже добавлен на Stage

Вот именно, товарищ in4core, дело в том глядя на абстрактный кусок кода невозможно судить о том, что и зачем. Это может быть загруженная извне флешка, которая ещё не поместилась на экран, но уже жаждущая скушать stage. А может быть MainController чего-то, что и на стейдже никогда не появится. Ну, так сложилось.

Надуманно? Согласен. Но вот что действительно круто: хозяин кода догадался не перегружать контроллер ненужной болмотнёй по дожиданию доступности stage'a, а сразу передал его в конструктор. Это минус несколько строчек в коде контроллера, это повышения читабельности и гибкости, внимая на моё суждение выше. Такие вот мелочи и создают чистоту и элегантность кода.

Babylon
31.08.2013, 17:47
Передавать ссылки на stage в конструкторе любого класса используемого как части MVC как минимум не логично. В целом представленный код мне не нравится.

in4core
01.09.2013, 00:30
Это можно напридумывать, что угодно. Передавать ссылку на стейдж в контроллер - моветон. Тем более нет таких решений, где это может быть нужно, пока хост не добавлен в список. Есть определенная организация кода. Контроллер лишь ждет наступления сеанса, до нужного момента.
Ну вот хоть лоб себе отбей - тру мвсишники передают в главный контроллер ( а здесь он ГЛАВНЫЙ, черт побери ) - только хост, и возможно, именно ВОЗМОЖНО , loaderInfo.parameters - и то это уже лишнее, ибо после создания контроллера, мы передаем хост, у стейджа которого есть нужны нам параметры.

Psycho Tiger
01.09.2013, 01:26
тру мвсишники
А где можно почитать про критерии тру-мвсишника? Тоже хочу таким стать.

in4core
01.09.2013, 15:21
Перефразирую, для непонятливых :) Люди, которые разбираются в данном паттерне и написали не мало приложений, базируясь на нем.

Dukobpa3
01.09.2013, 15:26
Люди которые хоть в чем-то разбираются - не будут утверждать что какое-то единичное решение единственно верное. Так как эти люди (уже) понимают, что задачи могут быть разными, и решения могут разными. И все они могут быть в парадигме паттерна.

in4core
01.09.2013, 16:09
Dukobpa3 - в мейн контроллере основного приложения - решение единственно верное, описанное мной выше. Тут нечего обсуждать. Если бы стоял разговор про загружаемую флешку, про дочерний контроллер и т.п. - так пожалуйста, пути неисповедимы , а тут путь один, другой путь - моветон. Закончил.

Dukobpa3
01.09.2013, 16:14
Ну раз так то чего уж)))
Будем учиться у великих))

Psycho Tiger
01.09.2013, 16:21
Паттерн – это типичная задача, под которую можно предоставить типичную реализацию в псевдокоде. А тут эмвэцэ, скинни-фэтти контроллеры, непонятно чья задача общаться с сервером, оправдывание существования "главного контроллера", оправдывание использования эмвэцэ без медиаторов...

Столько вопросов и так мало ответов. А оказывается – всё уже задокументировано единичной реализацией.

Думаю, не я один буду очень рад внять опыта от профи, который смог обобщить это всё. in4core, делись, где встретить такого человека?

Dukobpa3
01.09.2013, 16:28
@Psycho Tiger, Так это же in4core и есть. Просто скрывается.

in4core
01.09.2013, 16:40
Psycho Tiger - ты полностью отходишь от темы, совершенно начинаешь нести пургу о другой части, не о той, которая стоит в вопросе. Причем тут задача общения с сервером и stage главного контроллера? Что за бред. Ты заработался походу, нефиг тут филосовстовать - тут конкретно поставленный вопрос был, на который есть конкретный ответ.
Ну, а уж если ты хочешь поговорить о сервере, который тут вообще не причем. То общаться с сервером как раз задача контроллеров, а вот каких именно - непонятно в любом случае, но не то, чтобы непонятно, тут нет четкой постановки. У меня например в приложениях с сервером общаются почти все контроллы, главный общается с методами стейтов ( начало игры, конец игры и т.п.) , например, а дочернии контролы общаются с методами, ну например , методами функционирования инвентаря или каких то других мини боксов, к примеру. Но это опять все сугубо личное, у каждого свое. Да , я и сам говорил ни раз, что МВС - тема то философская , тут нет четко поставленной задачи, но в некоторых местах, она все же есть, иначе бы формулировки паттерна не было. Так вот и с главным контроллером - new MainController(host) , new BaseModel(БЕЗ НИЧЕГО), new BaseView(...rest) . Понятно дело, что от концепции всегда можно отойти, придумать свою - именно для этого и создан МВС, но написать например new BaseModel(this._server) - можно сразу руки рубить.

Psycho Tiger
01.09.2013, 17:01
Вопрос был в описании "паттерна MVC".
Когда ты пишешь о том, что паттерн создан для того, чтобы отойти от его концепции – это значит что ты не понимаешь предназначение паттернов.
Когда ты называешь архитектуру паттерном – это значит что любая архитектура у тебя под копирку. Это значит что ты не растёшь над собой.
Когда ты утверждаешь что "общение с сервером задача контроллера" – это значит что ты используешь "толстый контроллер". Всё бы ничего, но твоя формулировка четко отдаёт главным: ты не понимаешь, зачем придумали MVC. Ты используешь его "потому что это круто и все так делают" и держишь в уме заготовленную фразу "ну это типа отделяет отображение от логики".
Но что хуже всего: у тебя нет желания саморазвития. Это выражается в отсутствии взглядов на MVP, MVVM, Model Delegate или даже примитивно похудевший контроллер, который повышает модель из статуса Observable VO в статус действительно модели. И это даже без взгляда на твои недавние топики с вопросами, которые стоило разобрать, ну не знаю, года 2 назад?

Извини если что-то сказал обидное, но я глубоко тобой разочарован.

Babylon
01.09.2013, 17:04
Лучше бы обсудили имплементацию нескольких интерфейсов у класса Вида или Модели и их взаимодействие с соответствующими proxy классами. PTiger любит абстрактно порассуждать. Не вижу ничего плохого.

in4core
01.09.2013, 17:55
Ни в коем случае, я не обижаюсь, ты сказал все верно, я уже давно не развиваюсь в этой сфере, дабы не испытываю большой нужды, у меня четко поставленная концепция разработки программ на МВС, лишнего мне не надо. А вот по поводу - пишу на нем потому что МОДНО - тут не прав, я пишу, потому что это очень УДОБНО, удобнее, пока ничего не встречал, как в плане дописывания модулей, так и в плане быстрой организации любого приложения.
Psycho Tiger. Давай тогда поставим вопрос ребром. ( не знаю как у тебя, у меня программирование это второй заработок , скорее больше хобби ). У меня нет ОГРОМНОГО ( подчеркну это слово, дабы тем не менее всегда узнаешь, что то новое) желания развития дальше в этой сфере
а) Все, что я знаю - достаточно для того, чтобы писать хороший, чистый код, который будет выполнять то, что от него требуется
б) У меня нет ни одного приложения, которое не работает или работает с глюками.
в) У меня стабильная клиентура, которая мной полностью довольна, мне не нужно рыпаться по фриланс сайтам ища работу за копейки.
г) При том, что это мое хобби, так скажем, мой заработок составляет в среднем 3000$ в месяц.
И так, я имею все, что нужно, а так же высокий ЗП, даже по МСК, если считать. О каком саморазвитии мне нужно подумать, скажи мне, студент? Сидеть, читать книжки по паттернам, статьи на форумах англоязычных и т.п., ради лишь того, чтобы сидеть тут с тобой и мерится письками, кто лучше понимает МВС? Ну это просто смешно.
Да несомненно, это может еще и пригодится работая в команде флешеров, но меня данная стезя не привлекает , подстариваться под кого то, соблюдать конвенции принятые только в данном офисе и т.п. - фу и фу. :)
На самом деле ты еще просто молод, вот и прет у тебя юношеский максимализм, типа я круче всех, могу со всеми поспорить и т.п. - ну это не плохо и не хорошо, это в порядке вещей, с возрастом придет осознание, и естественно ты забудешь, о том, как сидеть и пояснять всем , что такое MVP, а что MVVM , у тебя будут слегка другие приоритеты в жизни :) Удачи.
И я думаю далее, лучше помоги человеку, который задал вопрос, дабы тема вроде как не для холивара, а не спорь со мной, все равно не переспоришь)))

Babylon
17.09.2013, 04:16
http://jessewarden.com/2012/08/backbone-js-for-flash-and-flex-developers.html

Akopalipsis
30.09.2013, 00:44
Прежде чем начать оправдываться, хочу поблагодарить in4core за его труд!
Если бы не он, то возможно я бы и не получил ответа, на свой глупый вопрос.
Такой "код".. я даже не буду говорить от куда он взялся, лучше его раз и навсегда забыть.
Статью Psycho Tiger я не один раз прочёл, но возможно и вправду что то не допонял. Ещё есть догадка, что меня не понимают из-за того, что я хочу сделать так, как в жизни не когда не делают.

Dukobpa3
30.09.2013, 01:12
Примерно так.
Контроллер инитит модель и вью.
Вью подписывается на модель.
Контроллер подписывается на вью.
Когда из вью что-то прилетает в контроллер - он может дернуть модель и что-то в ней поменять. А модель в свою очередь собщит об изменении наружу.
Так что всё грубо говоря верно, только кода мало, думаю когда будет больше - появятся еще вопросы.

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

Т.е. именно эту ситуацию лучше было решить без контроллера вообще.
В модели лежит словарь:
{ 0:0xF5F5D6, 1:0xDBF5D6}
А вью при клике просто лезет в модель и смотрит нужный цвет.

//==========================

Второй вариант.

Так как сделал ты. Но в модели есть переменная : currentColor
И в методе в котором у тебя свитч и диспатч пачки событий наружу - просто установка значения в эту переменную, и диспатч ОДНОГО события CHANGE вконце.

Вью получает событие, и рисует model.currentColor

//====================

Короче идея в том что в модели не только логика. Но и данные.
Т.е. логика которая не меняет данных - модели не очень нужна. Хотя туда можно добавить какие-то методы типа: function getCurrentColorByButtonIndex(id:int):uint //(который по сути геттер, и дергается он не из контроллера, а из вью)

Akopalipsis
30.09.2013, 02:07
Dukobpa3 Спасибо Вам за помощь!
я удалил предыдущий код, добавил изменённый + новый класс -...
думаю когда будет больше - появятся еще вопросы.
Так и есть, я просто сначала убедиться хочу, что самое минимальное понимаю, а потом уже продвигаться к тому, что я вообще не знаю как сделать. По этому ушёл делать пример дальше, чтобы Вам понятней было.
package
{
import flash.display.Sprite;

public class Main extends Sprite
{

public function Main()
{
new BaseController(this);
}

}

}
package
{
import flash.display.DisplayObjectContainer;
import flash.events.DataEvent;

public class BaseController
{
private var _doc:DisplayObjectContainer;

private var _model:Model;
private var _view:View;

private var _storageObject:Object =
{

}

public function BaseController($doc:DisplayObjectContainer)
{
super();

_doc = $doc;

_model = new Model();
_model.DOCSize = [_doc.root.parent.stage.stageWidth, _doc.root.parent.stage.stageHeight];
trace(_doc.root.parent)
_view = new View(_model);
_view.addEventListener('MENU', view_viewClickHandler);

_doc.addChild(_view);
}

private function view_viewClickHandler(event:DataEvent):void
{
_model.accessStatus(event.data);
}

}

}
package
{
import adobe.utils.CustomActions;
import flash.events.Event;
import flash.events.EventDispatcher;

public class Model extends EventDispatcher implements IModel
{
private var _DOCSize:Array = [];
private var _getColor:uint ;

private var _menuStatus:String;

public function Model()
{
super();

}
public function accessStatus($button:String):void
{
if ($button == '0')
{
if (_menuStatus == $button) return;
_menuStatus = $button;trace(';;;;;;;;;;;')
_getColor = 0xA8F2ED;
dispatchEvent(new Event('MODEL_MENU'));
}
else
if ($button == '1')
{
if (_menuStatus == $button) return;
_menuStatus = $button;
_getColor = 0xEBF2A8;
dispatchEvent(new Event('MODEL_MENU'));
}
else
if ($button == '2')
{
return;
}
else
{
throw new Error('ERROR');
}
}

public function get DOCSize():Array
{
return _DOCSize;
}

public function set DOCSize(value:Array):void
{
_DOCSize = value;
}

public function get getColor():uint
{
return _getColor;
}

public function set getColor(value:uint):void
{
_getColor = value;
}

}

}
package
{
import flash.events.IEventDispatcher;

public interface IModel extends IEventDispatcher
{
function accessStatus($button:String):void;
function get DOCSize():Array;
function get getColor():uint ;
}

}
package
{
import flash.display.Sprite;
import flash.events.DataEvent;
import flash.events.Event;
import flash.events.MouseEvent;

public class View extends Sprite
{
private var _model:IModel;

private var _button:Button;
private var _menuContainer:Sprite;
private var _backgraund:Sprite;

public function View($model:IModel)
{
super();

this.mouseEnabled = false;

_model = $model;
_model.addEventListener('MODEL_MENU', model_modelMenuHandler);

_backgraund = new Sprite();
_backgraund.mouseChildren = false;
_backgraund.mouseEnabled = false;
_backgraund.graphics.beginFill(0xF7E1D5);
_backgraund.graphics.drawRect(0, 0, _model.DOCSize[0], _model.DOCSize[1]);
_backgraund.graphics.endFill();
super.addChild(_backgraund);


this.addEventListener(MouseEvent.MOUSE_DOWN, this_mouseDownHandler);


var id:int = 0;
_menuContainer = new Sprite();
_menuContainer.name = 'menu';
super.addChild(_menuContainer);

for (var i:int = 0; i < 3; i++)
{
_button = new Button();
_button.id = id++;
_button.x += 72 * i;
_menuContainer.addChild(_button);
}


}

private function model_modelMenuHandler(event:Event):void
{
_backgraund.graphics.clear();
_backgraund.graphics.beginFill(uint(_model.getColor));
_backgraund.graphics.drawRect(0, 0, _model.DOCSize[0], _model.DOCSize[1]);
_backgraund.graphics.endFill();
}

private function this_mouseDownHandler(event:MouseEvent):void
{
super.dispatchEvent(new DataEvent('MENU',false,false,event.target.id));
}

}

}
package
{
import flash.display.Sprite;

public class Button extends Sprite
{
private var _id:int;

public function Button()
{
this.graphics.beginFill(0xA9B6F1);
this.graphics.drawRect(0, 0, 70, 45);
this.graphics.endFill();
}

public function get id():int
{
return _id;
}

public function set id(value:int):void
{
_id = value;
}

}

}

in4core
30.09.2013, 19:56
_model.DOCSize = [_doc.root.parent.stage.stageWidth, _doc.root.parent.stage.stageHeight];
_model.DOCSize = [_doc.stage.stageWidth, _doc.stage.stageHeight];

_view.addEventListener('MENU', view_viewClickHandler); Тут лучше делать кастом, типа ViewEvents - это хорошая практика. Так же стоит называть константы логично, например MENU_CLICK_EVENT!!

$button:String) Аналогично - называйте логично, кнопка не может быть строкой, сам же потом запутаетесь. В моделе так же создать кастом ModelEvents - И делать адекватные имена MODEL_CUSTOM_EVENT.

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

public function View($model:IModel) Я бы посоветовал привыкать к
view.model = someModel. То есть к сеттерам , а не передаче в конструктор. Потому, что если моделей надо будет больше пихать их в конструктор, ну не очень красиво, да и на момент создания конструктора они могут быть Null.

super.dispatchEvent(new DataEvent('MENU',false,false,event.target.id));
Нужно так :
dispatchEvent(new DataEvent(DataEvent.MENU_CUSTOM_EVENT, target.id));

Добавлено через 2 минуты
Ну и наконец, зачем вам все это надо то? Что вы хотите получить? Какое то приложение делаете или что? Если свой сайт решили писать, я могу показать, как это будет в MVC эквиваленте, конечно не идеально, но похожеее на правду

Akopalipsis
30.09.2013, 22:08
in4core Спасибо за учение, я естественно всё учел и ещё у меня есть один вопрос - вот там где Вы писали про кнопку, что она не может быть строкой... я вчера когда делал события, то первым делом вспомнил, что желательнее использовать события нативные, так как такая практика в будущем поможет делать легко переносимые модули. Но когда я дошел до кода с кнопкой, то сразу пришёл к выводу, что лучше сделать свое событие, куда добавить пункт самого обьекта-target и уже полноценно считывать его id. И ещё одним аргументом в пользу собственного события было сообщение, когда говорили, что вот по таким строковым сравнениям, как раз можно попасть в неприятную ситуацию. По этому - как лучше делать, нативными сообщениями со строкой или собственное событие с передачей target?
Ну и наконец, зачем вам все это надо то? Что вы хотите получить?
Получить я хочу умение писать код по шаблону MVC так, чтобы не один человек не смог сказать что там что то не так. По этому я учась и не куда не спеша, начал с самого минимального и со временем буду наращивать обороты и ждать одобрения. И я бы не отказался посмотреть реализацию чего то.

in4core
01.10.2013, 03:57
Получить я хочу умение писать код по шаблону MVC так, чтобы не один человек не смог сказать что там что то не так. По этому я учась и не куда не спеша, начал с самого минимального и со временем буду наращивать обороты и ждать одобрения. И я бы не отказался посмотреть реализацию чего то.
Всегда, кто нибудь да что то скажет - это интернет. Не бывает хорошего МВС, вот с чего надо начинать. Бывают разные реализации.
Кто вам сказал что нативные события лучше испольщовать чем кастомные? Ничего подобного - делать надо так, как удобоваримо и располагает ситуация. Чтобы ответь на вопрос передачи таргета,строк или еще чего, надо сначала сформулировать задачу, типа хочу чтобы по клику на меню создавался модуль Б и т.п. Тогда вам подскажут - а пока говорить неочем

Akopalipsis
26.10.2013, 01:21
Не знаю когда закралась ко мне в голову эта мысль, но точно знаю, когда я решил, что её уже не оставлю без внимания - этот момент наступил после этого поста (http://www.flasher.ru/forum/showpost.php?p=1149573&postcount=191). Но я не думал, что у меня появится ещё одна мысль, которая побудит меня на столь раннее задание этого вопроса.
Вот все говорят, что вью не имеет ссылки на контроллер ( и как считаю я, только по этому не рассматривают ПЛЮСЫ от этого ), но если немного отдалится от этого и забыть о EventDispatcher, то как бы она могла передать массив данных требуемые в модели? Или вью, которая посылая события EventDispatcher ( по сути калбеки ), разве не имеет ссылку на контроллер? Ведь это одно и тоже... В чем я не прав?
И хоть застрелите, но я тоже подсел на эту тему, не могу не чего с собой поделать))

Psycho Tiger
26.10.2013, 13:56
Вью имеет ссылку на контроллер на уровне приложения, но не на уровне кода, с которым ты работаешь.
Ядро может быть сколь-угодно-криво-написанное, но если оно имеет хорошее API и достаточный функционал – тебе никогда не придется лезть в это ядро, а сам ты сможешь писать хороший код, который легко поддерживать.

Wolsh
05.11.2013, 15:38
Что лично мне не нравится в событиях от Вью к Контроллеру?
Это вобщем-то отлично, когда ничего кроме типа События не требуется.
Но как только возникает ситуация, когда необходимо передавать данные, весь смысл меняется.
Становятся необходимы особые кастомные классы Событий-контейнеров данных. Эти классы должны знать (то есть иметь с ними жесткую связанность) и Вью и Контроллер. Я уже как-то "наезжал" на такую же проблему с событиями от Модели к Вью, и здесь ситуация ничем не лучше. Разруливать ее с помощью неких "интерфейсов событий" имхо маразм, особенно когда напрягает само количество новых классов-Событий, каждый из которых нужен для поддержки одного единственного действия юзера во Вью/изменения данных в Модели — так к каждому еще и Интерфейс заводить?
Я к тому, что в ситуации неявной жесткой связанности через события говорить об идеалах независимости фигурантов MVC довольно лицемерно, а учитывая сильную физическую/логическую связь между Вью и Контроллером (второй, по сути, придаток Вью), я лично вполне допускаю схему с прямой ссылкой и прямым вызовом методов контроллера из вью-хозяина. "Передать массив" в такой ситуации не потребует ни нового Класса События, ни Интерфейса для него, а связанность, по сути, та же самая. Реальную независимость имеет только Модель, и ей ничто не угрожает.

Котяра
05.11.2013, 15:52
Если вместо контроллера использовать PM (Presentation Model)
То именно так там и делается.
http://www.martinfowler.com/eaaDev/PresentationModel.html
http://blogs.adobe.com/paulw/archives/2007/10/presentation_pa_3.html
http://examples.pmwilliams.co.uk/adobeblog/presentationpatterns/presentationmodel/srcview/index.html
http://examples.pmwilliams.co.uk/adobeblog/presentationpatterns/presentationmodel/srcview/source/class-diagram.jpg

lammer.Ok
01.02.2014, 04:02
Подскажите и мне в вопросе. При загрузке программы, кто грузит все необходимые картинки и тд. для UI? Например, у меня готовится редактор, и мне необходимо подготовить и загрузить много картинок для тулбара. Кто этим занимается из mvc или эту функцию выполняет совершенно левый класс, какой-нибудь UILoader ?

Dukobpa3
01.02.2014, 05:10
Менеджмент ресурсов не входит в задачи модели.

Менеджмент ресурсов так же не входит и в задачи контроллера.

Методом исключения приходим к тому что картинки должны быть во вью(ну и очевидно что она ведь их отображает). А откуда вью их возьмет - уже ваша задача придумать.
И вьюха например сама должна знать что для статуса модели "вкл", она должна отобразить картинку "зеленая_галочка.жпг".
Вью может ссылку на эту галочку взять из отдельной какой-то модели-конфига со словарем урлов по иду или готовую картинку из какой-то фабрики.

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

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

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

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

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

Dukobpa3
02.02.2014, 03:50
Всё верно, но пару комментариев.

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

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

Тут может будет для вас что-то интересное:
рас (http://www.flasher.ru/forum/blog.php?b=677)
два (http://www.flasher.ru/forum/blog.php?b=676)

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

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

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

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

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

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

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

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

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

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

Dukobpa3
08.02.2014, 22:24
Могу своими решениями поделиться разве что.

Изначально было следующим образом:
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 более удобна, но чисто мое субьективное мнение - удобнее с контроллером.

Котяра
09.02.2014, 02:41
надо просто не упарваться и просто писать код.

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

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

caseyryan
25.03.2014, 16:35
то получается, что вью ещё не создана и отображать некому.
Так в чем проблема создать-то?

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

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

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

Dukobpa3
25.03.2014, 17:49
Проблема, которую я надеюсь Вы поможете решить, в построении логики.
Весь форум уже вкурсе что у вас, юный падаван, проблемы с логикой ;)
*trollface.jpg*

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

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

Как-то так.

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

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

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

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

lammer.Ok
27.10.2014, 04:36
Есть здесь кто живой? %)

in4core
27.10.2014, 18:09
А тебе зачем?

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

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

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

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

lammer.Ok
29.10.2014, 16:10
- mvc - это уровень архитектуры приложения, тащить его в реализацию рендера единственной вьюхи не стоит
Почему не стоит? Это же удобно. Например, у меня модель всей сцены хранит модели всех инструментов отображенных вьюшкой сцены. Когда пользователь хочет сохранить рисунок, все модели сериализуются в один xml или json-объект и загружаются на сервер. Когда хочет загрузить рисунок, то опять же, xml парсится, фабрики создают модели и вьюшки, а контроллер сцены выдаёт контроллер инструмента, который будет связывать все MV инструмента. Вьюшка сцены хранит все вьюшки инструментов, она слушает дополнительно дочерние вьюшки и контролирует частоту перерисовки. При запросе удаления инструмента удаляется его модель и вьюшка. Как по мне так достаточно удобно использовать MVC и для инструментов. К тому же в данной теме также советуется использовать MVC и для часто рисующихся объектов.
- я бы сделал модель холста, и в ней бы хранил все линейки (в том числе), а обновлятся модель будет и так на каждый тык
- линейка простой класс, отрисовщик и дизайнер (который слушает клики на линейке и таскает её), дизайнер диспатчит сигналы-ивенты о изменениях в вью/медиатор (как и все остальные инструменты)
Эту часть я не совсем понял. То есть, получается у нас есть класс "Линейка", который сам себя считает и рисует. Когда мы хотим удалить линейку со сцены, то, к примеру, медиатор, связывающий вьюшку холста и все инструменты кричит вьюшке холста удалить тек. экземпляр линейки из ёё коллекции ? Так ?

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

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

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

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

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

lammer.Ok
29.10.2014, 17:58
- а если у вас будет 40 типов на холсте (линейки, круги, н-гоны, сетка, имажи, дравы ...) вы к каждому будет писать медиатор/вью? и каждый тип будет крутиться в ядре mvc тормозя отрисовку холста, а там обычно нужно ооооочень быстро рисовать.
Зачем для всех? Один медиатор для всех и отдельная вьюшка для каждого. Но согласен, это избыточно и соб-но по-этому обратился на форум.

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

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

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

ShockWave512
29.10.2014, 18:13
Всё вроде бы выглядит логично, но почему событие удаления объекта не приходит в контроллер сцены и он не сообщает модели удалить объект?
да через контроллер правильно
это я привык мухлевать напрямую в модель, а контроллеры использую только для важных моментов приложения (загрузка, запуск главного вида, сохранение/загрузка)

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

ShockWave512
29.10.2014, 18:54
"модель прослушивания модели"?

я делал бы просто, CanvasModel.onChange.add() (onSelect) , все желающие сидят на этом событии/сигнале, в том числе и ваше инфо окно, у всех инструментов есна должен быть интерфейс для снятия инфы ) или использовать существующий метод toString()

lammer.Ok
29.10.2014, 19:19
Ага, тоже вариант. Но можно будет ещё подумать.
А так, спасибо большое, что помогли разобраться в проблеме. Вопросов больше нет ;)

Gerbert
29.10.2014, 19:24
Всё вроде бы выглядит логично, но почему событие удаления объекта не приходит в контроллер сцены и он не сообщает модели удалить объект?
А что именно Вы удаляете, что вид диспатчит контроллеру, чтобы тот передал модели, чтобы модель передала виду - удалить - что?)

lammer.Ok
29.10.2014, 19:31
Вид диспатчит "удаление объекта", контроллер говорит модели "удалить объект", а модель сама возьмёт тек. выбранный объект и удалит.

Gerbert
29.10.2014, 19:39
Удаление иконки или нарисованной шкалы?

Добавлено через 9 минут
Мне вообще кажется, что какую-то линейку нельзя рядом с mvc ставить.
В плане mvc можно рассматривать редактор для рисования, но не линейку.
Вам нужно подумать, что общего у всех инструментов. Вот я вижу, что выбрав линейку я НАЖИМАЮ и не отпускаю
кнопку мыши и передвигая инструмент РИСУЮ и затем ОТПУСТИВ прекращаю рисовать. Далее, взяв кисть я НАЖИМАЮ
и не отпускаю кнопку и передвигая инструмент РИСУЮ, после чего ОТПУСТИВ кнопку перестаю рисовать.
И мне кажется, что под этот алгоритм подходят все инструменты. И у них у всех общее, это СОСТОЯНИЯ.

Добавлено через 13 минут
И теперь нужно подумать, что именно здесь нужно модели...
Я нарисовал, я стер, я поставил фигурку.. Тут все делает вид и мне сложно представить,
куда втиснуть модель. Возможно модели можно поручить смену состояний у вида, но тут нужно подумать,
является ли состояние ЛОГИКОЙ приложения.

Добавлено через 15 минут
Вот если взять широкую кисть и нарисовать ей смайл, то как это повлияет на логику работы приложения,
относительно тонкой кисти?

lammer.Ok
29.10.2014, 19:55
Gerbert
Я осознал свою ошибку, мне уже всё объяснили)

Gerbert
29.10.2014, 19:55
И получается, что данные относящиеся к настройкам кисти не должны быть в модели, так как это не логика.

Добавлено через 1 минуту
Я к тому, что модель не должна говорить виду, что нужно удалить то, что к логике не относится.

lammer.Ok
29.10.2014, 20:04
Так модель виду ничего и не собирается говорить)

Gerbert
29.10.2014, 20:09
модель удаляет объект -> кричит всем что данные сменились, вью холста ловит это и обновляет холст
Всё вроде бы выглядит логично, но почему событие удаления объекта не приходит в контроллер сцены и он не сообщает модели удалить объект?
Мне просто показалось, что вы обсуждаете диспатч из модели в представление, для удаления чего-то.

lammer.Ok
29.10.2014, 20:22
Ну в данном случае модель хранит все объекты добавленные на холст, вьюшка кнопки удаления свистит контроллеру холста, что пользователь хочет удалить объект, контроллер приказывает модели холста произвести удаление, модель берёт тек. выбранный объект и удаляет его из своей коллекции, ну и диспатчит какое-либо событие если надо для вьюшки холста.

Gerbert
29.10.2014, 20:30
А зачем модель хранит вью в себе? Потом ещё DO начнут удалятся child.parent.removeChild( this ) и после останется только головой с разбегу об стену ударится, чтобы забыть такое))

lammer.Ok
29.10.2014, 20:45
модель удалит объект вьюшки из своей коллекции и передаст вьюшке по обновлению displayObject для удаления. Модель хранит вьюшки для того, чтобы ими можно было управлять через контроллер холста из любого участка приложения.

Gerbert
29.10.2014, 20:48
Я могу только посоветовать прочесть эту и все другие статьи и темы на форуме.

lammer.Ok
29.10.2014, 21:42
Нет, согласен, что логично хранить все вьюшки инструментов во вьюшке холста, но тогда придется во вьюшку холста кидать ссылки на другие вьюшки, которые будут ей сообщать, что-то сделать с тек . инструментом. Например у меня есть инструмент "Полигон" его можно удалять, накладывать фильтры, резать, ломать, кусать с абсолютно разных меню и что мне во вьюшке холста хранить ссылки на вьюшки, которые будут сообщать о модификации тек. инструмента?

Gerbert
29.10.2014, 22:40
Нет! Логичней хранить инструменты в виде, который представляет программу.

Вам нужно забыть все, что вы напридумавали и на минутку закрыть глаза и расслабиться.
И представить, что Вы разрабатываете графический редактор и чтобы Вам было легче,
Вы решили сделать это при помощи mvc.

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

А задумка поместить отображение в модель, это вообще полная mvc-ересь.

Добавлено через 11 минут
И добавлю - Ваши инструменты, это всего лишь иконки и несколько строк кода для манипуляции с bitmapData,
по на них не стоит зацикливаться. Графический редактор, а точнее отображение, должно быть реализовано
через паттерн "состояния" где есть интерфейс IDraw ( я не умею писать так по английски ) с методами -
draw() это для всех рисовалок и IFilter c методом apply. И должна быть коллекция реализующая эти интерфейсы.
И об рисовании и применениях фильтров вообще нет смысла знать в модели. Я даже сомневаюсь, что данные для отката шагов нужно в модель записывать.

Добавлено через 27 минут
Сложно даже придумать, для чего нужна модель. Здесь состояние, коллекция, итератор, медиатор, представление, возможно еще что-то типа контроллера-презентер..
Хотя можно забить на все и сделать из mvc state machine, сделав из модели селектор..
Может более опытные направят, но я больше не знаю что сказать. Mvc тут только для переключения каких-то окошек-вкладок...

etc
30.10.2014, 00:26
Ого, а тема-то живёт, оказывается. Ну надо же :)

Psycho Tiger
30.10.2014, 10:30
Ого, а тема-то живёт, оказывается. Ну надо же :)
Да. С течением времени у меня ускользнула та мысль, ради которой голосовали за толстый контроллер и тупую модель.

lammer.Ok
30.10.2014, 16:08
Gerbert,
То есть вы хотите сказать, что mvc не подходит для граф. редактора и необходимо всю структуру перепроектировать?
У меня есть пдф-ка "Шаблон проектирования графического редактора" А.В. Шлиткин. так там такое определение: "графический редактор представляет собой модель и операции по изменению модели." Ещё: "В самом общем виде графический редактор имеет модель данных и графический интерфейс,
а поэтому к нему применима модель MVC2. MVC2 модели соответствует Model. MVC2 контроллеру — Tool. MVC2 View — Visualizer и Canva". Блин, кому верить тогда? Я теперь запутался...
etc
Ого, а тема-то живёт, оказывается. Ну надо же
для меня эта тема о mvc лучшая в инете.

Gerbert
30.10.2014, 17:27
Я хочу сказать, что мы говорим о разном, я об том, что представлению не место в модели,
а Вы о том, что правильно ли использовать mvc при создании рисовалки.

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

lammer.Ok
30.10.2014, 18:21
Я прочитал данную тему раз 5, но никто не делал и не даст абсолютно правильного решения. Мой опыт mvc крайне мал и получен от данной темы, но я никогда не хранил представление в модели, а только лишь id-объектов представления. Я лишь защищал возможность модели крикнуть состояние "удаление" для представления, чтобы оно взяло тек. id у модели и удалило дочернее представление. Да, у нас модель как бы не обновляется, то есть все значения остаются прежними, она лишь сигнализирует о своём тек. состоянии своей вьюшке. Таким образом две независимые вьюшки смогли сработаться через контроллер и модель. Да, логика модели как бы нарушается, она не должна говорить вьюшке что ей делать, её вообще не должно касаться, что вьюшки будут делать с данными. Но как сделать по-другому, не нарушая логику mvc?
Я СОГЛАСЕН, что НАРУШАЮ MVC.
Давайте оставим граф. редактор в покое и возьмём квадратики и кружочки, которые можно удалять и добавлять на сцену, как бы вы спроектировали mvc, поделитесь опытом, пожалуйста.

Gerbert
30.10.2014, 19:18
Мой опыт mvc крайне мал и получен от данной темы, но я никогда не хранил представление в модели, а только лишь id-объектов представления.
Вы не помните того, что говорили вчера?
модель удалит объект вьюшки из своей коллекции и передаст вьюшке по обновлению displayObject для удаления. Модель хранит вьюшки для того, чтобы ими можно было управлять через контроллер холста из любого участка приложения.
Я прочитал данную тему раз 5
Если мы выяснили, что Вы не помните вчерашние слова, а мы это выяснили,
то значит Вам нужно в шестой и седьмой раз прочитать. А то я не понимаю, как Вам объяснять
если Вы вчера говорите о DO в модели и я целый вечер Вам объясняю, что это фигня, а сегодня
Вы все отрицая, просите объяснить что-то другое.

lammer.Ok
30.10.2014, 21:15
Я написал это не подумав, так делать нельзя, не сразу это понял. Но удаление представлений у меня идёт через тек. состояние модели, а вы также, на сколько я понял, такой способ не поддерживаете. Как же всё-таки поступать.

Gerbert
30.10.2014, 21:32
Посмотрите вот это (http://easyflash.org/flashlearn/flashvideotutorials/o-shablone-sostoyanie) и потом напишите здесь, является ли реализация из урока лучше Вашей или нет и потом уже можно будет продолжать.

lammer.Ok
31.10.2014, 20:21
Ну очевидно, что так удобнее использовать графические инструменты. Но не ясно, где хранить нарисованные объекты(любой объект можно перетаскивать на сцене), кто их будет хранить, удалять, добавлять, слушать их события и тд.

Gerbert
31.10.2014, 21:10
Мне кажется, что Вы угараете, от нечего делать. Вы говорите, что храните DO в модели, а на следующий день говорите, что так не делаете. Когда Вас цитируешь, то Вы говорите, что "написали не подумав" и "так делать нельзя" и ещё на следующий день опять спрашиваете, где хранить представления. Но зато, цитирую!
Я прочитал данную тему раз 5
Вспомнилась фраза из кинчика - "Я есть Грут".

Добавлено через 8 минут
Вам нужно наверное прямо сказать - вьюшки хранятся во вьюшках, контроллеры, в контроллерах, модели в моделях.
И добавить - и только!

Добавлено через 13 минут
Но не ясно, где хранить нарисованные объекты(любой объект можно перетаскивать на сцене), кто их будет хранить, удалять, добавлять, слушать их события и тд.
Это к mvc не относится. Это уже, как Вам лучше. Приложение собирается, как пирамида, из кусков, а не монолитом, как гора.

lammer.Ok
31.10.2014, 21:51
Это к mvc не относится
Я пытаюсь и понять, если это не относится к mvc, то к чему это относится?
Я бы хранил вьюшки нарисованных объектов во вьюшке сцены, так как они к ней непосредственно относятся. Удалял, добавлял, слушал их вьюшкой сцены и тд. Но вы говорите, что данные операции к mvc не относятся.

Gerbert
31.10.2014, 22:26
У Вас должна быть главная вью, она создает вью холста и вью слоев ( вью слоев, это блок-меню, который отображает миниатюры слоев ). И теперь смотрите... Вью холста и вью слоев, это к mvc не относится, это два завершенных модуля.
Модуль, в том смысли, в котором говорят о законченном продукте, который автономный, то есть может переходить из проекта в проект и с которым общаться можно, только посредством api. То есть, классы полностью инкопсулированы.

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

Забудьте о моих словах тогда и делайте как хотите. Читайте статью, книги, форум и делайте.
Я больше не буду отвечать, а то Вы на меня повесите все свои проблемы и скажите, что это меня слушали.


Или если хотите, сделайте маленький пример - два квадрата, которые друг на друга заходят ровно на половину.
По клику мышки, они меняют глубину местами, то один выше, то второй. И при каждом клики пользователь получает +10
очков. И по завершению 20 секунд, в trace нужно вывести сумму всех очков.

Вот это тех задание для девочки с первого курса, которые банеры делает.
Только Вам нужно сделать на mvc.
Это не шутка и не предлог отделаться, это для дальнейшего объяснения.
Если вы это не сможете сделать, то фотошоп уж точно рано. И сделайте так, как видите mvc.

lammer.Ok
01.11.2014, 03:34
Или если хотите, сделайте маленький пример - два квадрата, которые друг на друга заходят ровно на половину.
По клику мышки, они меняют глубину местами, то один выше, то второй. И при каждом клики пользователь получает +10
очков. И по завершению 20 секунд, в trace нужно вывести сумму всех очков.
Так как на as3 не программирую написал простой псевдокод.
Пусть это будет упрощенная игра. Тогда у нас есть GameModel, GameView и GameController. Также есть класс-вьюшка RectangleView.

//Главный класс, инициализирует MVC
Main {
model = new GameModel();
view = new GameView(model);
controller = new GameController(model, view);
}

Model

//Модель
GameModel {
gameOver = false; //состояние игры
score = 0; //очки

//устанавливает и диспатчит состояние игры
setGameOverState(flag) {
gameOver = flag;
dispatchEvent(Event.CHANGE_STATE);
}
//возвр. состояние игры
getGameOverState() {
return gameOver;
}
//суммирует и диспатчит очки
addScore() {
score += 10;
dispatchEvent(Event.CHANGE_SCORE);
}
//возвр. очки
getScore() {
return score;
}
}

View

//Представление
GameView {
model; //модель игры
box1; //вьюшка прямоугольника 1
box2; //вьюшка прямоугольника 2
canvas; //холст

//конструктор
constructor(_model) {
model = _model; //получаем модель игры
canvas = new Canvas(); //создаём холст
//создаём вьюшки прямоугольников
box1 = new RectangleView(canvas, 150, 150, 1);
box2 = new RectangleView(canvas, 75, 150, 2);

//подписываемся на событие нажатия мыщи на прямоугольники, вызываем метод диспатча добавления очков
box1.addEventListener(MouseEvent.MOUSE_DOWN, dispatchAddScore);
box2.addEventListener(MouseEvent.MOUSE_DOWN, dispatchAddScore);

//подписываемся на событие изменения очков игры, вызываем метод, который переставляет глубину для кажлого из прямоугольников
model.addEventListener(Event.CHANGE_SCORE, swapBoxes);
//подписываемся на событие изменения состояния игры, вызываем метод вывода кол-ва очков
model.addEventListener(Event.CHANGE_STATE, showScore);

//запускаем таймер игры, по окончанию таймера вызываем метод, который диспатчит окончание таймера
setTimeout(dispatchTimerOver, 20000);
}
//показывает кол-во очков пользователя
showScore() {
//если состояние конца игры - true
if (model.getGameOverState() == true) {
trace(model.getScore()); //воводим кол-во очков
}
}
//меняет местами глубины прямоугольников
swapBoxes() {
box1Depth = box1.getDepth();
box1.setDepth(box2.getDepth());
box2.setDepth(box1Depth);
}
//диспатчит добавление очков
dispatchAddScore() {
dispatchEvent(Event.ADD_SCORE);
}
//диспатчит окончание таймера
dispatchTimerOver() {
dispatchEvent(Event.TIMER_OVER);
}
}

Controller

//Контроллер
GameController {
model; //модель игры
view; //вьюшка игры

//конструктор
constructor(_model, _view) {
model = _model; //получаем модель
view = _view; //получаем вьюшку

//подписываемся на событие добавления очков, изменяем в модели очки
view.addEventListener(Event.ADD_SCORE, addScore);
//подписываемся на событие окончания таймера, изменяем состояние игры
view.addEventListener(Event.TIMER_OVER, setGameOverState);
}
//добавляет очки в модели
addScore() {
model.addScore();
}
//меняет состояние игры
setGameOverState() {
model.setGameOverState(true);
}
}



RectangleView {
//тут ничего интересного, всё обычно
}

Gerbert
01.11.2014, 12:23
Тогда прошу прощения за отнятое время. Я хотел Вам продемонстрировать хирургию,
и попросил сделать вскрытие лягушки, а в ответ получил тарелку супа. Все тонкости ушли
и я не хочу навязывать Вам флешевою модель mvc, так как в Вашем языке может и не быть реализованно
того, что есть в as3 и я только наврежу. Во всех языках разное mvc/ По этому я диалог прекращаю.

lammer.Ok
01.11.2014, 19:33
Ответьте на несколько вопросов и закончим с этим. Я опишу, что у меня уже готово. От вас прошу лишь только подсказать или подкорректировать логику архитектуры.
Пока с вами переписывался кое-что переосмыслил и написал отдельный модуль Node(узел), который любую фигуру построенную из линий(потом и для кривых сделаю) расширяет до отдельного узла на сцене, то есть нарисовали, предположим, ромб, то эту фигуру можно перетаскивать через внутренний модуль DragAndDrop в главном модуле Node. Также сделал слушатель событий мыши, удаление и добавление для фигур. Теперь я хочу сделать, как вы мне написали, вьюшку Layer, куда будут добавляться вьюшки нарисованных объектов. Главная вьюшка сцены будет хранить в себе список слоёв layers. Главная модель сцены будет хранить id тек. выбранного слоя из списка layers. То есть теперь из любого меню приходит команда удалить слой, контроллер меняет состояние главной модели deleteLayer = true, вьюшка сцены слушает изменение состояния модели, берёт тек. слой по id из модели, кричит всем чайлдам удалить все узлы, когда все узлы удалились слой передает сообщение вьюшке сцены и она его удаляет из своей коллекции. Как вам такая идея?

Gerbert
01.11.2014, 20:52
<the свои слова обратно и предложу продолжить постижение самых-самых основ.
Делаю это не для того, чтобы у Вас исчерпались вопросы, а для того, чтобы Вы
сами научились на них отвечать.

Продолжим... Вот у Вас есть готовый код игры и заказчик просит Вас сделать ещё одну.
Задание такое - на сцене пустота, а при клике мышки создается кружок в месте клика.
При каждом клики пользователь получает +10 очков. И по завершению 20 секунд, в trace нужно
вывести сумму всех очков.

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

lammer.Ok
01.11.2014, 21:05
Задание такое - на сцене пустота, а при клике мышки создается кружок в месте клика.
При каждом клики пользователь получает +10 очков. И по завершению 20 секунд, в trace нужно
вывести сумму всех очков.
Это все представить в mvc виде? Псевдокодом или подучить as3 и сделать рабочий вариаант?

Gerbert
01.11.2014, 22:04
Я немного погорячился и Ваш псевдокод вполне приемлем, так что меня не напрягет, если Вы его в том же ключе будете соблюдать. А вообще странно, что Вы не зная as3 обсуждаете тему здесь. Вы на каком языке пишите?
И да, в виде mvc.

lammer.Ok
01.11.2014, 22:28
Сижу здесь потому что лучше и богаче темы о mvc не видел. К тому же иногда есть у кого-нибудь из форумчан уточнить детали. Программирую на java/c#/javascript, знаю as2, но язык не важен, главное окончательно разобраться в самом принципе mvc.
И да, в виде mvc.
на самом деле для новой "задачи" хватит одной вьюшки из mvc) Нечего выводить в модель и контроллер.

Gerbert
01.11.2014, 22:55
Делайте, а то ошибку не увидите.

lammer.Ok
02.11.2014, 00:51
Я догадываюсь в чём ошибка - неточное использование модели?

//Модель
GameModel {
gameOver = false;
score = 0;

setGameOverState(flag) {
gameOver = flag;
dispatchEvent(Event.CHANGE_STATE);
}

getGameOverState() {
return gameOver;
}

addScore() {
score += 10;
//не кричим вьюшке
}

getScore() {
return score;
}
}

//Представление
GameView {
model;
canvas;

constructor(_model) {
model = _model;
canvas = new Canvas();

model.addEventListener(Event.CHANGE_STATE, showScore);
stage.addEventListener(MouseEvent.MOUSE_DOWN, drawCircle);
setTimeout(dispatchTimerOver, 20000);
}

drawCircle() {
//тут типа окуружность рисуется и добавляется на сцену
circle = new CircleView(canvas, canvas.mouseX, canvas.mouseY);
}

showScore() {
if (model.getGameOverState() == true) {
trace(model.getScore());
}
}

dispatchAddScore() {
dispatchEvent(Event.ADD_SCORE);
}

dispatchTimerOver() {
dispatchEvent(Event.TIMER_OVER);
}
}

//Контроллер
GameController {
model;
view;

constructor(_model, _view) {
model = _model;
view = _view;

view.addEventListener(Event.ADD_SCORE, addScore);
view.addEventListener(Event.TIMER_OVER, setGameOverState);
}

addScore() {
model.addScore();
}

setGameOverState() {
model.setGameOverState(true);
}
}

//Вьюшка Окружности
CircleView {
//рисуется окружность
}

Gerbert
02.11.2014, 00:56
Вы неправильно определяете логику приложения, то есть модель, а из этого вытекают и все последующие ошибки. Нужно научится отделять логику от представления и это уже mvc.
Прежде всего ответьте на вопрос - что в первом случаи логика и что логика во втором.
И вот только эта логика и должна быть в модели.

lammer.Ok
02.11.2014, 02:07
И в первом и во втором случае логика это подсчёт очков и наверное запуск таймера.

Gerbert
02.11.2014, 15:22
И в первом и во втором случае логика это подсчёт очков и наверное запуск таймера.
В том-то и дело, что логика, это очки и таймер. А все остальное, это представление.
Логика, это то, без чего приложение не будет приложением. Можно подумать, что таймеру и во вью неплохо,
но если заменить вью на другую, то таймера может и не быть и приложение сломается.

Я бы прежде всего разобрался с BaseView и выяснил, что будет входить в её обязанности.
Просто бывают моменты, когда удобней, чтобы Base или MainView выступала ещё и в роли
Mediator'a. Медиатор нужен для того, чтобы CanvasView, различные MenuBoxView могли общаться между собой.
Можно сделать отдельно медиатор, который будет связывать все представления событиями.
И этот же медиатор будет прокси для контроллера. То есть, медиатор будет хранить немного логики,
которая не должна находится в контроллере, а должна находится в представлении.
Эта логика и будет решать, передать событие в какую-то вью или передать в контроллер.

Далее, у Вас должен быть класс Слой, который реализует всевозможные интерфейсы - IDrag, IFilter и тд.
Так же должна быть фабрика этих слоев.
И когда Вы щелкаете по кнопке "создать новый слой", посылается событие, которое ловит медиатор.
Что делать с этим событием? Если у Вас логика приложения гласит "в этом приложении нельзя создать более
ста слоев", то медиатор должен послать сообщение для контроллера, который изменит модель.
Ну а дальше медиатор или модель посылает событие, которое ловит другой медиатор ( медиатор создания слоев )
и он уже берет из фабрики новый экземпляр класса Слой и.. И дальше уже Ваша фантазия - Вы можете передать его сразу во все можули ( драг, филтры и ... ) либо же просто отдать в коллекцию слоев и в канвас для addChild.

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

lammer.Ok
02.11.2014, 16:53
Спасибо, очень ценный ответ. Не зря потратил время. Теперь прояснились многие непонятные моменты с моделями и я почему-то недооценил роль медиаторов для взаимодействия с представлениями, пытаясь привязать представления строго к моделями из-за чего и получил неудачную и неясную структуру. Спасибо вам за потраченное время, всё здорово и понятно изложено. Вопросов больше нет.

П.С. я не пытаюсь написать фотошоп, но хочу сделать продуманный костяк, на котором можно будет написать любой графический редактор.