VMC помогите разобраться

33 views
Skip to first unread message

andrey Vichodcev

unread,
Jan 19, 2009, 4:10:47 AM1/19/09
to ruF...@googlegroups.com
я так понял, что модель  - это наследник ЭвентДиспечера. ссылка на который передается в качестве параметра во все представления. то есть в случае с флэшом это root???
и патерн VMC практически встроен  во флэш?

Daniil Tutubalin

unread,
Jan 19, 2009, 4:27:31 AM1/19/09
to ruF...@googlegroups.com
root - это View

Модель - это нечто абстрактное, не имеющее само по себе никакого
внешнего вида (и соответственно может быть отражено по-разному).
Если Модель наследуется от DisplayObject - то это уже не совсем
правильная модель.
Например, здоровье и количество патронов у персонажа - это Модель. А
индикаторы на экране, которые отображают эти данные (в виде чисел, или
полосок жизней или ещё каким-то образом) - это Вид.

andrey Vichodcev

unread,
Jan 19, 2009, 4:37:58 AM1/19/09
to ruF...@googlegroups.com
то есть вся проблема в том что root является ВЬЮ?
чем это мешает?

а если в качестве МОДЕЛИ использовать Global? хотя все против него )))

Cemaprjl

unread,
Jan 19, 2009, 5:10:31 AM1/19/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

> то есть вся проблема в том что root является ВЬЮ?
> чем это мешает?
>
> а если в качестве МОДЕЛИ использовать Global? хотя все против него )))
Модель это не просто что-то отдельное от вида.
В зависимости от задач вашего приложения это все-же должен быть набор
осмысленных классов.

советую к прочтению книжку Гамма, Хелм - "Приемы
объектно-ориентированного проектирования: паттерны проектирования"
там отлично расписаны основные шаблоны проектирования

допустим у вас есть некая модель содержащая данные: A=10, B=20, C=500,
D=250 и т.д.
у этой модели есть интерфейсный метод: getData():Array и событие которое
всплывает при изменении модели - например Event.CHANGE
вы создавая отображение этой модели подписываетесь на указанное событие
когда оно всплывает получаете данные и отображаете их

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

так же советую заглянуть в PureMVC фреймворк - одна из лучших реализаций
паттерна на данный момент

Valentin Simonov

unread,
Jan 19, 2009, 5:32:42 AM1/19/09
to ruF...@googlegroups.com
MVC

andrey Vichodcev

unread,
Jan 19, 2009, 7:11:26 AM1/19/09
to ruF...@googlegroups.com


MVC
да конечно.

Модель это не просто что-то отдельное от вида.
В зависимости от задач вашего приложения это все-же должен быть набор
осмысленных классов.
МОДЕЛЬ должна быть набором классов? мне казалось что модель это ОДИНОЧА или нет? ну или один и тот же экземпляр передается в качестве параметра всем ПРЕДСТАВЛЕНИЯМ? а какая у него иерархия наследования не важно.
а что мешает в AS3? Document class - Main.
понятно что root должен реализовывать возможность хранения нужных данных. не понятно коректно ли это. есть ли какие подводные камни мешающие использованию root.
сравнение с другими вариантами?
глобал.
МОДЕЛЬ должна
1. реализовывать возможность хранения/изменения данных
2. оповещая всех заинтересованных в случае изменения данных
3. быть переданной всем ПРЕДСТАВЛЕНИЯМ в качестве переменной дабы они могли забирать нужные им данные
ничего не забыл?
поэтому мне и кажется что root наиболее хорошо подходит для этих целей.
1. реализовать в root хранение/изменение данных можно
2. root наследник ЭвентДиспечера
3. передается во все потомки DisplayObject

если просто создать свой класс реализующий МОДЕЛЬ от ЭвентДиспечера и не сделать его Document class возникает проблема передавать ссылку на этот объект всем ПРЕДСТАВЛЕНИЯМ.
использовать глобал???

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


Denis Kolyako

unread,
Jan 19, 2009, 7:14:57 AM1/19/09
to andrey Vichodcev
Здравствуйте, andrey.

> МОДЕЛЬ должна быть набором классов? мне казалось что модель это
> ОДИНОЧА или нет?

Модель может повторять структуру View, точнее, View повторяет
структуру модели.
Т. е. модель вполне себе древовидна может быть.

>
> если просто создать свой класс реализующий МОДЕЛЬ от ЭвентДиспечера
> и не сделать его Document class возникает проблема передавать ссылку
> на этот объект всем ПРЕДСТАВЛЕНИЯМ.
> использовать глобал???

Собственно, в чем проблема вызвать сеттер модели у View?

Денис Коляко
______________________________________________________________________
e...@timezero.ru | http://etcs.ru/ | http://www.timezero.com/

ign

unread,
Jan 19, 2009, 7:16:34 AM1/19/09
to ruF...@googlegroups.com
Уважаемый, подразумевается, что вы сами будете передавать модель нужному
вьюверу.
А ссылка на root есть по умолчанию у всех. Что уже неправильно. Так же
подразумевается, что состояние модели
может изменять только контроллер. А у вас любой объект может достучаться
до методов рута. И т.д.
Заведите отдельный класс для модели и будет вам счастье.

--
ign
_____________________________________________________________________
http://www.isky.ru

Valentin Simonov

unread,
Jan 19, 2009, 7:54:57 AM1/19/09
to ruF...@googlegroups.com
PureMVC на самом деле очень маленький.
Что мне не нравится — впихивать мелкие действия по командам и отсутствие возможности "слушать" у прокси, хотя это и правильно.

Вообще, друг, такое ощущение, что ты не понимаешь смысл MVC.
У тебя есть 3 абстракции: модель, отображение и контроллер.
Модель — содержит данные, грузит данные, конвертирует данные. Этакий черный ящик с интерфейсом.
Отображение — показывает что-нибудь.
Контроллер — обрабатывает действия пользователя через отображения, отдает команды модели и  управляет отображениями.
Как-то так.

А непосредственно интерпретация может быть очень разная. Например, один объект на view, model и controller. Или много view, один controller, одна модель. Или много Proxy в одной модели.

Смысл в том, что мы отделяем управление от данных и отображения.

Непосредственно по твоему письму, оповещение views может быть сделано множеством способов. Во флекс фреймворках используется data binding, в puremvc notifications и view о модели не знают ничего, где-то используются ссылки непосредственно на модель, хотя мне кажется это неправильно.

Андрей Скорик

unread,
Jan 19, 2009, 8:29:59 AM1/19/09
to ruF...@googlegroups.com
mate - рулит :))

Какой-нть Application manager - за модель
EventMap - контроллер
ну а виды видами.. 

mxml-фреймворк.
инъекция данных из модели в виды :)  - кэширование объектов и тд.. короче куча вкусностей. и очень компактно.

Valentin Simonov

unread,
Jan 19, 2009, 8:39:00 AM1/19/09
to ruF...@googlegroups.com
и компактный flex framework в придачу

andrey Vichodcev

unread,
Jan 19, 2009, 9:30:47 AM1/19/09
to ruF...@googlegroups.com
А ссылка на root есть по умолчанию у всех. Что уже неправильно.
чем? в моделе хранятся общие для всех данные. и все имеют к ним доступ. что тут неправильно? думаю с любой реализации MVC все представления завязаны с моделью. у нас же все DisplayObject связаны с root???
Так же
подразумевается, что состояние модели
может изменять только контроллер.
а что такое контроллер? все что меняет модель и то что мы сами и написали. откуда возьмется "какой то" контроллер который будет менять модель, а мы про него не будем ничего знать?
 

andrey Vichodcev

unread,
Jan 19, 2009, 9:31:10 AM1/19/09
to ruF...@googlegroups.com
Модель ― содержит данные, грузит данные, конвертирует данные. Этакий черный ящик с интерфейсом.
я полога что  Модель только содержит данные и оповещает об их изменении. все остальное делает контроллер?

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


ign

unread,
Jan 19, 2009, 9:40:58 AM1/19/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

>
> А ссылка на root есть по умолчанию у всех. Что уже неправильно.
>
> чем? в моделе хранятся общие для всех данные. и все имеют к ним
> доступ. что тут неправильно? думаю с любой реализации MVC все
> представления завязаны с моделью. у нас же все DisplayObject связаны с
> root???
При таком подходе вы не соблюдаете один из основных принципов
объектно-ориентированного программирования. Имя ему - инкапсуляция.
Модель хранит данные только для вьюверов, никому больше эти данные не нужны.

Denis Kolyako

unread,
Jan 19, 2009, 9:43:49 AM1/19/09
to ign
Здравствуйте, ign.

> Модель хранит данные только для вьюверов, никому больше эти данные не нужны.

А контроллерам?

andrey Vichodcev

unread,
Jan 19, 2009, 9:45:41 AM1/19/09
to ruF...@googlegroups.com

Модель хранит данные только для вьюверов, никому больше эти данные не нужны.
у нас же все DisplayObject связаны с root. или все представления связаны с моделью?

Denis Kolyako

unread,
Jan 19, 2009, 9:47:39 AM1/19/09
to andrey Vichodcev
Здравствуйте, andrey.

> у нас же все DisplayObject связаны с root.

Связаны. И что? Не нужен представлениям рут, совершенно. Максимум,
что должно волновать View — так это то, что внутри этого View лежит.

ign

unread,
Jan 19, 2009, 9:50:27 AM1/19/09
to ruF...@googlegroups.com

>> Модель хранит данные только для вьюверов, никому больше эти данные не нужны.
>>
>
> А контроллерам?
>
>
Контроллеру нужная прямая ссылка на модель, чтобы изменять ее состояние.

Андрей Скорик

unread,
Jan 19, 2009, 9:52:18 AM1/19/09
to ruF...@googlegroups.com
:) глубоко извиняюсь. думал пишу в рассылку ruFlex :))



и компактный flex framework в придачу


--
С уважением, Скорик Андрей. andrew...@gmail.com

Valentin Simonov

unread,
Jan 19, 2009, 10:01:04 AM1/19/09
to ruF...@googlegroups.com
у нас же все DisplayObject связаны с root. или все представления связаны с моделью?

вообще говоря, это справедливо для дисплейобжектов в дисплей листе

andrey Vichodcev

unread,
Jan 19, 2009, 10:07:13 AM1/19/09
to ruF...@googlegroups.com
вообще говоря, это справедливо для дисплейобжектов в дисплей листе
а зачем вообще работать представлению которое не в дисплей лист?

Denis Kolyako

unread,
Jan 19, 2009, 10:07:48 AM1/19/09
to ign
Здравствуйте, ign.

> Контроллеру нужная прямая ссылка на модель, чтобы изменять ее состояние.

Так а чем ссылка для вьюверов отличается от ссылки для контроллеров?

ign

unread,
Jan 19, 2009, 10:15:16 AM1/19/09
to ruF...@googlegroups.com

>> Контроллеру нужная прямая ссылка на модель, чтобы изменять ее состояние.
>>
>
> Так а чем ссылка для вьюверов отличается от ссылки для контроллеров?
>
[quote]

Модель хранит данные только для вьюверов, никому больше эти данные не
нужны.
[/quote]

Подразумевалось, что данные модели требуются только вьюверу.
А ссылка на саму модель естественно нужна и контроллеру и вьюверу.

andrey Vichodcev

unread,
Jan 19, 2009, 10:16:32 AM1/19/09
to ruF...@googlegroups.com
  Так а чем ссылка для вьюверов отличается от ссылки для контроллеров?
ничем. но вьюверам она прописывается моделью, а в контроллер попадает из вьювера.

Denis Kolyako

unread,
Jan 19, 2009, 10:19:47 AM1/19/09
to ign
Здравствуйте, ign.

> Подразумевалось, что данные модели требуются только вьюверу.

Неужели? А смысл от контроллера, если он не пользуется данными из
модели?

andrey Vichodcev

unread,
Jan 19, 2009, 10:22:13 AM1/19/09
to ruF...@googlegroups.com
Подразумевалось, что данные модели требуются только вьюверу.
 а контроллер не может в своей работе использовать данные модели? допустим пользователь может перемешать объект в определенных пределах. представление скажет контроллеру что объект перемещен, а как обработать это перемещение и откуда взять данные это задача самого контроллера или нет?

ign

unread,
Jan 19, 2009, 10:26:38 AM1/19/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

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

Denis Kolyako

unread,
Jan 19, 2009, 10:26:37 AM1/19/09
to andrey Vichodcev
Здравствуйте, andrey.

> ничем. но вьюверам она прописывается моделью, а в контроллер попадает из вьювера.

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

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

ign

unread,
Jan 19, 2009, 10:28:00 AM1/19/09
to ruF...@googlegroups.com
Denis Kolyako пишет:

> Неужели? А смысл от контроллера, если он не пользуется данными из
> модели?
>
Смысл контроллера в том, чтобы отслеживать взаимодействие с
пользователем с помощью вьювера и оповещать модель об изменениях.

Denis Kolyako

unread,
Jan 19, 2009, 10:35:31 AM1/19/09
to ign
Здравствуйте, ign.

> Смысл контроллера в том, чтобы отслеживать взаимодействие с
> пользователем с помощью вьювера и оповещать модель об изменениях.

Контроллер модель не оповещает, он её изменяет. А для этого ему
могут потребоваться данные из модели и при определенных условиях он
не будет изменять модель.
Т. е. он не настолько примитивен, чтобы тупо полученные от View
данные засовывать сразу в модель.

Андрей Скорик

unread,
Jan 19, 2009, 10:38:37 AM1/19/09
to ruF...@googlegroups.com
Смысл контроллера  в том, чтобы отслеживать взаимодействие с
пользователем с помощью вьювера и оповещать модель об изменениях.

ну не совсем уж только.. так... а чьей функцией например будет запросить сервер и обработать результат?

я бы скорее сказал что модель это просто данные и методы для их чтения/записи/ выборок и тд...

а вот модификация, данных, процедуры расчета...парсер ответа сервера и тд... это все же наверное ближе контроллеру....

поучил от вида сигнал "а-а-а-а в меня тыкнули мышой!!". посмотрел кто кричит. ага маленькая такая кнопка из панели авторизации. запросил сервер. получил ответ, разобрал  - положил в модель. крикнул: Эй представления!!! пользуйтесь!!!

ign

unread,
Jan 19, 2009, 10:41:34 AM1/19/09
to ruF...@googlegroups.com

> ну не совсем уж только.. так... а чьей функцией например будет
> запросить сервер и обработать результат?
А не сама ли модель должна это сделать?

Denis Kolyako

unread,
Jan 19, 2009, 10:41:34 AM1/19/09
to Андрей Скорик
Здравствуйте, Андрей.

> получил ответ, разобрал  - положил в модель.
> крикнул: Эй представления!!! пользуйтесь!!!

Крикнул точно не контроллер.
Да и получать команды от сервака чаще всего не обязанность того
контроллера, который клик получил. Ну только если это не специфичная
для данного компонента команда.

Denis Kolyako

unread,
Jan 19, 2009, 10:44:05 AM1/19/09
to ign
Здравствуйте, ign.

>> запросить сервер и обработать результат?
> А не сама ли модель должна это сделать?

Модель не содержит логику.

ign

unread,
Jan 19, 2009, 10:52:03 AM1/19/09
to ruF...@googlegroups.com

> Крикнул точно не контроллер.
> Да и получать команды от сервака чаще всего не обязанность того
> контроллера, который клик получил. Ну только если это не специфичная
> для данного компонента команда.
>
Модель диспатчит евент, что она изменилась, вьюверы их ловят и
перерисовывают?

Андрей Скорик

unread,
Jan 19, 2009, 10:56:23 AM1/19/09
to ruF...@googlegroups.com
> Крикнул точно не контроллер.

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

... ну про сервак это просто пример. может быть не самый удачный )). но в общем цепь то такова...

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

вид тоже ленив.. ну лейауты, ну инпуты, ну диспатч.. ну край средства трансформации данных необходимым для данного вдиа способом (adapter)

а вот контроллер (ну хорошо система контроллеров) - это трудяга...

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

Denis Kolyako

unread,
Jan 19, 2009, 10:56:54 AM1/19/09
to ign
Здравствуйте, ign.

> Модель диспатчит евент, что она изменилась, вьюверы их ловят и
> перерисовывают?

Да, этот процесс происходит без какого-либо дальнейшего вмешательства
со стороны контроллера.

Valentin Simonov

unread,
Jan 19, 2009, 10:57:06 AM1/19/09
to ruF...@googlegroups.com

 Модель не содержит логику.

содержит логику работы с данными
 

Андрей Скорик

unread,
Jan 19, 2009, 11:02:21 AM1/19/09
to ruF...@googlegroups.com
проводя аналогию "модель-ящик" :)) добавлю - что ящик, то может, конечно, иметь и замочки и финдибоберные крышечки и двойное дно... но суть его от этого не меняется. он ящик. он - место хранения. и не больше.

Denis Kolyako

unread,
Jan 19, 2009, 11:07:19 AM1/19/09
to Valentin Simonov
Здравствуйте, Valentin.

> содержит логику работы с данными

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

andrey Vichodcev

unread,
Jan 20, 2009, 1:38:13 AM1/20/09
to ruF...@googlegroups.com
а модель не сама получает первоначальные данные?
просто если модель-ящик, то откуда в нем берутся данные которые потом изменяются контролерами?
и кто создает первоначальное состояние? добавляет в цепочку отображения нужные ПРЕДСТАВЛЕНИЯ и связывает их с МОДЕЛЬЮ?

допустим у нас есть три мувиклипа (ПРЕДСТАВЛЕНИЯ) их можно тоскать мышкой.
1. синий кубик.
2. желтый кубик.
3. зеленый кубик.

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

как это реализовать с помощью MVC?
в моделе нам нужны данные только по координатам мувиков, так? и в моделе будет 6-ть публичных переменных (синий_х,синий_у и т.д.)? или три объекта (синий, желтый и т.д.) и у них уже свои (х,у) ???
1. загружаем наши данные и помещаем их в МОДЕЛЬ. (кто этим занимается в данном патерне?)
2. помещаем наши кубики на сцену инициализируем стартовыми данными и подписываем на прослушивание изменений (опять таки кто этим занимается?).
у модели будет три события - ИзменениеДляСинего, ИзменениеДляЖелтого, ИзменениеДляЗеленого. а ПРЕДСТАВЛЕНИЯ будут сами забирать нужные данные. или правельнее сделать отдельное событие для каждого изменения? типа ИзменениеДляСинегоПоУ?
3. ПРЕДСТАВЛЕНИЕ создает свой КОНТРОЛЛЕР и подписывает его на свои события.
4. по получении события от ПРЕДСТАВЛЕНИЯ КОНТРОЛЛЕР обрабатывает его. в нашем случае КОНТРОЛЛЕРЫ синего и желтого должны менять не только данные полученные от ПРЕДСТАВЛЕНИЯ.
5. проверку на недопустимость значения (ведь наши кубики могут двигаться только в заданных пределах), осуществляет МОДЕЛЬ? или это тоже работа КОНТРОЛЛЕРА?




 



Cemaprjl

unread,
Jan 20, 2009, 1:44:06 AM1/20/09
to ruF...@googlegroups.com

> Ну это само собой, просто логику, необходимую для работы самой
> модели и правильности хранения данных, я не считаю за логику :-D
>
>
>
Друзья, а ведь модель - это не обязательно модель данных, это может быть
модель какого-нибудь процесса.
и я считаю что логика вполне может быть в модели. По определению GOF -
Модель - это объект приложения а Контроллер описывает как ГУЙ реагирует
на действия пользователя.

вот допустим у нас модель карточной игры - объект приложения (Модель)
"колода" - где вы будете делать метод тасования?

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

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

з.ы. и по поводу аналогии - "ящик должен всего-лишь хранить данные" -
тоже не согласен. Смысл определения "черный ящик" говорит о том что у
нас есть интерфейс какой-нибудь системы, ну пусть это будет какой-нибудь
мп3-плейер. интерфейс нам позволяет тыкать на кнопочки Play, Stop, Next
и т.п. а как он работает внутри нам знать не обязательно
Модель это не просто данные - это система.

Cemaprjl

unread,
Jan 20, 2009, 2:00:31 AM1/20/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

> допустим у нас есть три мувиклипа (ПРЕДСТАВЛЕНИЯ) их можно тоскать мышкой.
> 1. синий кубик.
> 2. желтый кубик.
> 3. зеленый кубик.
>
> когда мы передвигает синий, желтый тоже смещается на половину смещения
> синего и наоборот, при смещении желтого, синий смещается на два
> смещения желтого.
> все мувиклипы можножно тоскать в пределах определенной области.
> начальные положения загружаются из xml.
>
> как это реализовать с помощью MVC?
> в моделе нам нужны данные только по координатам мувиков, так? и в
> моделе будет 6-ть публичных переменных (синий_х,синий_у и т.д.)? или
> три объекта (синий, желтый и т.д.) и у них уже свои (х,у) ???
> 1. загружаем наши данные и помещаем их в МОДЕЛЬ. (кто этим занимается
> в данном патерне?)
вид строится по модели, а где вы возьмете данные - ваше дело - с сервера
ли, прохардкодите или еще как-то

> 2. помещаем наши кубики на сцену инициализируем стартовыми данными и
> подписываем на прослушивание изменений (опять таки кто этим занимается?).
> у модели будет три события - ИзменениеДляСинего, ИзменениеДляЖелтого,
> ИзменениеДляЗеленого. а ПРЕДСТАВЛЕНИЯ будут сами забирать нужные
> данные. или правельнее сделать отдельное событие для каждого
> изменения? типа ИзменениеДляСинегоПоУ?
смотря насколько масштабные изменения проходят в модели, если меняется
только X и Y то достаточно слушать CHANGE, а если помимо этого еще
десяток параметров меняется да еще и в разное время то лучше слушать
по-отдельности

> 3. ПРЕДСТАВЛЕНИЕ создает свой КОНТРОЛЛЕР и подписывает его на свои
> события.
скорее система (не знаю может быть тоже какая-нибудь модель в
зависимости от реализации) свяжет представление с конкретным
контроллером. т.к. контроллер определяет поведение системы в ответ на
действие Вьюшки - вы можете менять контроллеры для этого вида на лету -
напрмиер у вас желтый будет смещаться относительно синего не в 2 раза а
в 5, а зеленый будет появляться в случайном месте.

andrey Vichodcev

unread,
Jan 20, 2009, 2:21:14 AM1/20/09
to ruF...@googlegroups.com

вид строится по модели,
а кто этим занимается? или это не принципиальная для данного патерна вешь?

Cemaprjl

unread,
Jan 20, 2009, 2:26:50 AM1/20/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

>
> вид строится по модели,
>
> а кто этим занимается? или это не принципиальная для данного патерна вешь?
ну вид и занимается - берет данные например green_x и green_y и
устанавливает эту фигуру в нужное место
классом получающим данные о новых координатах фигур из вашего примера
должен быть контейнер содержащий эти фигуры

Ivan Dembicki

unread,
Jan 20, 2009, 3:55:16 AM1/20/09
to ruF...@googlegroups.com
Hello andrey,

MVC хороший паттерн, как и многие другие, но.
Не стоит стремиться всё загонять в шаблоны.
Их, конечно, надо знать и уметь применять.
Но просто программируй. Пиши так, как пишется.
Смотри, что получается. Избегай антипаттернов.
Не бойся рефакторить - хороший портной должен
очень любить пороть (не бдсм, хотя, может я
неправильно понимаю пословицу).
И, в итоге, сложится тот самый продукт,
который нужен.

Если твое письмо звучит именно в контексте
изучения MVC, то я для понимания вкратце
охарактеризовал бы его в первую очередь
как принцип разделения данных и представления
(M и V) и связку их контроллером (С).


--
iv
http://www.bezier.ru
http://bezier.googlecode.com

andrey Vichodcev

unread,
Jan 20, 2009, 4:52:39 AM1/20/09
to ruF...@googlegroups.com
да изучение MVC, и возможностей его реализации.
принцип в основном понятен.
за что отвечает каждый участник в принципе тоже понятно. хотя многие мнения противоречивы.

по реализации.
я понял, что для создания ПРЕДСТАВЛЕНИЯ придется использовать Proxy или ... .

а вот кто и как управляет созданием данной схемы работы не понятно.
в PureMVC для этого создается фасад.

не могу найти простого примера реализации с описание, что это у нас МОДЕЛЬ, это ПРЕДСТАВЛЕНИЕ ... для их связки мы выбрали вот такой вот способ из вот таких возможных, потому что... а тут мы выбираем ...
в теории то все красиво и правильно, а вот одно только использование Proxy на мой взгляд замедлит простой проект в разы.
опять таки примерно эта схема реализована (как я понял) во Flex. или нет?

Cemaprjl

unread,
Jan 20, 2009, 5:27:42 AM1/20/09
to ruF...@googlegroups.com
andrey Vichodcev пишет:

> по реализации.
> я понял, что для создания ПРЕДСТАВЛЕНИЯ придется использовать Proxy
> или ... .
Proxy в терминах PureMVC это скорее модель чем представление, шаблон
проектирования же с таким же названием несколько другую задачу решает

> а вот кто и как управляет созданием данной схемы работы не понятно.
> в PureMVC для этого создается фасад.
>
> не могу найти простого примера реализации с описание, что это у нас
> МОДЕЛЬ, это ПРЕДСТАВЛЕНИЕ ... для их связки мы выбрали вот такой вот
> способ из вот таких возможных, потому что... а тут мы выбираем ...
и не найдете, разве что станете разбирать реализацию существующего
проекта. говорить о этом паттерне можно бесконечно так же как и
вариантов реализаций тысячи.
Иван в предыдущем письме правильно написал что главное в MVC - это
разделение M и V

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


> в теории то все красиво и правильно, а вот одно только использование
> Proxy на мой взгляд замедлит простой проект в разы.
> опять таки примерно эта схема реализована (как я понял) во Flex. или нет?

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

dima.be...@gmail.com

unread,
Jan 20, 2009, 6:44:01 AM1/20/09
to ruFlash
Я тоже недавно с этим разбирался.
Вот хорошая статья. Разжовано, и всё применительно к AS3.
http://fla-master.livejournal.com/3972.html

Я только не согласен с автором, по поводу ссылок.
Кто на кого ссылки должен хранить.
Классический вариант:
Модель не имеет ссылок, ни на контроллер, ни на виды.
Модель ни о ком ничего не знает.
Вид имеет ссылку на модель.
Контроллер имеет ссылки на модель и вид.

Евгений Н.

unread,
Jan 20, 2009, 7:27:08 AM1/20/09
to ruF...@googlegroups.com

> Классический вариант:
> Модель не имеет ссылок, ни на контроллер, ни на виды.
> Модель ни о ком ничего не знает.
> Вид имеет ссылку на модель.
> Контроллер имеет ссылки на модель и вид.

Самый лучший вариант (придумал, к сожалению, не я, такая схема в
Swing, лучше лично я не встречал, даже на счет использования иньекций
можно бросить пару камешков, можно, можно, не сомневайтесь):

Модель не имеет ссылок (но диспатчит эвенты).
Вид не имеет ссылок (но диспатчит эвенты).

Контроллер имеет довольно глубокую иерархию наследования, от
более общих конструкций, до, например, абстрактного класса всех кнопок
вообще, и, "в конце" - конкретной кнопки (класс контроллера кнопки,
например JButton, объекты которого можно инстранцировать во многих
проектах).

Контроллер по умолчанию делает вот что:

1) Создал (через new) новый экземпляр View (причем берет класс для View - по
умолчанию тоже, например ViewDefault)

2) Создал (через new) новый экземпляр Model (тоже - ModelDefault)

3) Назначил подписку, себе, на события от Model и на событий от View.

ИТОГО:

1) Контроллер "просто" перенаправляет события между Model и View.

2) Model и View - не знают друг о друге.

3) Схема связывания, всего, реализованная в контроллере - ДИНАМИЧЕСКАЯ.
Это означает следующее - в процессе выполнения можно,
в контроллере, отписаться в нем от ТЕКУШЕЙ Model и от ТЕКУЩЕГО View,
УДАЛИТЬ экземпляры View и Model, создать (через new) НОВЫЕ
экземпляры Model и View, подписаться на события от Model и View.

4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но
при ИНСТАНЦИРОВАНИИ приложения, например, назначются такие объекты,
по умолчанию, т.е. у вас нет никаких null. И / или может быть и так -
в КОНКРЕТНОЙ реализации класса-контроллера, во всей иерархии
классов-контроллеров - метод инстанцирования View и Model - указан
более специализировано, в соотв. с тем, какие задачи выполняет
текущий контроллер.

P.S. Сюда бы еще пример кода, как поистине грамотно это все
реализовано в Swing , но лично у меня нет времени для этого, а
кто минимально знает Java - откройте в Eclipse класс JButton из
пакета Swing, и по кнопке F3 - доберитесь до первого абстрактного
класса, в иерархии наследования выше.
Так же обратите внимание на "систему именования" методов в модели
и др., которые диспатчат события - метод начинается со слова
"fire", далее указывается "слово" конкретного события. Кажется
так. Подобную систему видел и в других фреймворка, поэтому лучше
не лепить огород, а следовать "классике, в некотором понимании
этого вопроса.

Ivan Dembicki

unread,
Jan 20, 2009, 7:36:23 AM1/20/09
to ruF...@googlegroups.com
Hello Евгений Н.,

> Модель не имеет ссылок (но диспатчит эвенты).
> Вид не имеет ссылок (но диспатчит эвенты).

- видимо, ты имел ввиду "не получает ссылок в конструктор".
Т.к. раз вещает, то ссылки имеет.


> 4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но

- если не ошибаюсь, это еще один шаблон проектирования.
Нулевой объект. Null Object или как там, не поомню.
Идея заключается в том, что если в классе может быть, а может и не быть
какой-то подчиненный объект, то лучше создать пустой статический объект
и подложить его, а не проверять каждый раз ифами наличие этого объекта.

andrey Vichodcev

unread,
Jan 20, 2009, 7:44:43 AM1/20/09
to ruF...@googlegroups.com
3) Схема связывания, всего, реализованная в контроллере - ДИНАМИЧЕСКАЯ.
  Это означает следующее - в процессе выполнения можно,
  в контроллере, отписаться в нем от ТЕКУШЕЙ Model и от ТЕКУЩЕГО View,
  УДАЛИТЬ экземпляры View и Model, создать (через new) НОВЫЕ
  экземпляры Model и View, подписаться на события от Model и View.

не очень понял.
вроде весь смысл Model в том что он един. и многие View могут пользоваться одними данными. а в таком подходе какой смысл отписываться от Model? какой смысл в View для которого нет данных? что это View будет менять? может это уже какой иной паттерн?

Евгений Н.

unread,
Jan 20, 2009, 7:50:55 AM1/20/09
to Ivan Dembicki
>> Модель не имеет ссылок (но диспатчит эвенты).
>> Вид не имеет ссылок (но диспатчит эвенты).

> - видимо, ты имел ввиду "не получает ссылок в конструктор".
> Т.к. раз вещает, то ссылки имеет.

Да, высказался не совсем точно.

В общем контроллер имеет два privat поля, в одно из которых помещает
ссылку на View, в другое - ссылку на Model.

Сами View и Model - ничего не инстанцируют и ничем не пользуются.


>> 4) Зачем введено ViewDefault и ModelDefault. - Точно уже не помню, но
> - если не ошибаюсь, это еще один шаблон проектирования.
> Нулевой объект. Null Object или как там, не поомню.
> Идея заключается в том, что если в классе может быть, а может и не быть
> какой-то подчиненный объект, то лучше создать пустой статический объект
> и подложить его, а не проверять каждый раз ифами наличие этого объекта.

Да, такой есть. Честно говоря вот всю эту конструкцию я реализовывал
на AS2 года 2 назад, тогда же и вникал в Swing, сейчас уже в нюансах
так точно не помню. Паттерн Null Object в "прямом виде" там так не
использовался - вот что могу сказать. Сорри, если что.

Ivan Dembicki

unread,
Jan 20, 2009, 7:52:37 AM1/20/09
to ruF...@googlegroups.com
Hello andrey,

> вроде весь смысл Model в том что он един.

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

Евгений Н.

unread,
Jan 20, 2009, 7:57:22 AM1/20/09
to andrey Vichodcev

Помните, как во многих вещах - мы можем динамически менять dataProvider - ?


Например мы инстанцируем новый объект JButton, а ПОТОМ - назначаем/придаем ему какие-то свойства.


Например - более продвинутую (или - не стандартную, а "кастомную") модель.


В случае с XML структурами, например XML-деревом это может пригодится - создаем новую модель,

наследуясь от стандартной, "расширяем" стандартную реализацию (разработанную для МНОГИХ проектов) -

под конкретную реализацию в текущем проекте или для конкретного инстанцирования в таком-то месте.


Или можем так же динамически изменять / назначать - класс РАСПОЛОЖЕНИЯ элементов на экране. - Есть

некоторый метод set в качестве параметра которому, этому методу - передаем новый объект (в качестве

параметра этому методу, прямо там пишем new).


Надеюсь объяснил, сорри если что.

Denis Kolyako

unread,
Jan 20, 2009, 8:17:11 AM1/20/09
to Ivan Dembicki
Здравствуйте, Ivan.

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

Это линейная база данных, по сути. Каждый элемент является данными
по одной компании.
Гораздо интереснее древовидная база данных, по образу и подобию
очень похожая на структуру display object-ов. Можно даже с
бабблингом по базе данных.

Daniil Tutubalin

unread,
Jan 20, 2009, 8:21:21 AM1/20/09
to ruF...@googlegroups.com
> а зачем вообще работать представлению которое не в дисплей лист?

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

Пример:
addChild(new Bitmap(bitmapData));
bitmapData.draw(sprite);

andrey Vichodcev

unread,
Jan 20, 2009, 8:49:11 AM1/20/09
to ruF...@googlegroups.com


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

Пример:
addChild(new Bitmap(bitmapData));
bitmapData.draw(sprite);
 
addChild - уже в дисплэй листе?

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

Daniil Tutubalin

unread,
Jan 20, 2009, 8:50:10 AM1/20/09
to ruF...@googlegroups.com
Вот часто при описании MVC говорят: "модель изменяется и оповещает
представления, которые эти изменения показывают".
Однако в играх очень часто возникает необходимость отобразить
изменения модели не сразу, а с задержкой.

Пример: онлайновая азартная игра. Рулетка, слот, крепс, блекджек или
покер - это не важно, но для определённости возьмём рулетку.

Пришли данные от сервера: на рулетке выпал такой-то номер, эти ставки
выиграли, эти ставки проиграли, итоговый баланс игрока такой-то.
Модель как бы уже изменилась (как минимум баланс поменялся).
Но Представление №1 - рулетка - сперва должна покрутиться и на ней
попрыгать шарик.
Затем Представление №2 - игровой стол со ставками - должен плавненько
переместить чипы, выигрывшие - в одну стороны, проигравшие - в другую.
И только после всего этого Представление №3 - индикатор баланса -
должен отобразить новый баланс.

Как это реализуется в MVC?

Другой пример: некая динамичная игра, в которой игрок может как
получать очки, так и терять их.
Но нужно сделать так, чтобы при любом изменении очков новое значение
отображалось не моментально, а чтобы циферки "крутились".
Т.е. получил игрок 200 очков - в течении 20 кадров добавляется по 10
очков. Проиграл 100 очков - в течении 10 кадров уменьшается на 10
очков.

А теперь ситуация: игрок выиграл 500 очков (индикатор побежал вверх,
но ещё не добежал до целевого значения), почти тут же проиграл 300
очков, и спустя долю секунды опять выиграл 100 очков.

Опять же, как нам тут поможет MVC?

Ivan Dembicki

unread,
Jan 20, 2009, 8:51:05 AM1/20/09
to ruF...@googlegroups.com
Hello Denis,

> Гораздо интереснее древовидная база данных, по образу и подобию

> очень похожая на структуру display object-ов. [...]

- да, сразу вспоминаются мои эксперименты с XML
и попытки навесить классы на ноды :)
Т.е. по-сути из XML сделать иерархическую модель,
и затем навесить представление.
Глядя назад, думается, что идея интересная,
но сложная для реализации в AS1-2 и, к сожалению
(или к счастью), бессмысленная в AS3

Daniil Tutubalin

unread,
Jan 20, 2009, 8:53:47 AM1/20/09
to ruF...@googlegroups.com
> addChild - уже в дисплэй листе?

Пардон :) Нет, конечно :)

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

Ну, он может реагировать на enterFrame, например. Или, опять же, на
изменение модели, но по каким-то причинам, мы не хотим сразу
показывать спрайт, а сперва желаем пропустить его через мельницу
битмаповых преобразований.

ign

unread,
Jan 20, 2009, 8:55:58 AM1/20/09
to ruF...@googlegroups.com
Daniil Tutubalin пишет:

> Представление №1 - рулетка - сперва должна покрутиться и на ней
> попрыгать шарик.
> Представление №2 - игровой стол со ставками
> Представление №3 - индикатор баланса
> Как это реализуется в MVC?
>
>
Все три представления находятся в общем для них представлении.
Общее представление получает событие, что модель изменилась, и затем
анимированно проделывает все 3 операции с любыми задержками между ними?

--
ign
_____________________________________________________________________
http://www.isky.ru

Ivan Dembicki

unread,
Jan 20, 2009, 8:57:44 AM1/20/09
to ruF...@googlegroups.com
Hello Daniil,

> Опять же, как нам тут поможет MVC?

- MVC не панацея и не обязательство.
Изучая шаблоны не стоит шаблонировать мозг.
Не стоит пытаться загнать проект в шаблон.
Проект должен сам прийти в него уже процессе
программирования.

В представленных тобою случаях классическим
MVC не обойтись.
Обязательно возникнут дополнительные прокладки
для управления потоком событий.

Denis Kolyako

unread,
Jan 20, 2009, 9:02:00 AM1/20/09
to Daniil Tutubalin
Здравствуйте, Daniil.

> А теперь ситуация: игрок выиграл 500 очков (индикатор побежал вверх,
> но ещё не добежал до целевого значения), почти тут же проиграл 300
> очков, и спустя долю секунды опять выиграл 100 очков.

А в чем проблема? x += (targetX - x) / 20 на ENTER_FRAME, например :-)
targetX = текущее значение из модели.
Т. е. MVC как-то на визуальные эффекты не влияет совершенно, то, что вьювер с
запаздыванием показывает данные модели — это лишь особенности
реализации вьювера, модель же всегда содержит актуальные данные.

Евгений Н.

unread,
Jan 20, 2009, 9:05:24 AM1/20/09
to Daniil Tutubalin
Паттерн State, в обоих случаях.

MVC решает одни задачи, State решает другие задачи. В коопирировании,
получается, и будет сила ("В чем сила, брат?" (с))

andrey Vichodcev

unread,
Jan 20, 2009, 9:08:42 AM1/20/09
to ruF...@googlegroups.com
извини но опять таки не вижу смысла производить какие либо операция с визуальным объектом который не отображается.
да и зачем?
если при добавлении на сцену он должен получит все последние данные из модели?

Евгений Н.

unread,
Jan 20, 2009, 9:17:02 AM1/20/09
to Евгений Н.

> Паттерн State, в обоих случаях.

Например. Вот у вас есть игровой объект (условимся в терминах, пускай
игровой объект обозначает некую абстракцию в игре, например танк,
когда вы инстанцируете танк, то дистанцируете именно ИГРОВОЙ ОБЪЕКТ,
который в себе уже - содержит разные модели, виды, и еще много всего).


Т.е. мы сделали сейчас так, что данный игровой объект - СОДЕРЖИТ ту
конструцию MVC, который мы сделали ранее.

По какому-то событию - вам нужно например сейчас - ИЗМЕНИТЬ состояние
вашего игрового объекта, на такое состояние, при котором он мигает и
не реагирует на клики по нему мышку (в танк попал снаряд). - Что может
быть проще? - Дайте ему, этому игровому объекту - ДРУГУЮ реализацию
того, что показывается в игре. Это не View, это - "полный комплект",
вы динамически сейчас меняется.

Но комплект... на каком-то... низком... уровне...

Потому что MVC позволяет представить как вообще всю игру, сделанную по
патттерну MVC, так и ОТДЕЛЬНУЮ КНОПКУ в игре, сделанную по паттерну MVC.

И таким образом сюда можно "всунуть" паттерн State, динамически
подменяя, в ответ на какие-то события - что-то на что-то.

Евгений Н.

unread,
Jan 20, 2009, 9:24:11 AM1/20/09
to Евгений Н.

Динамически подменять состояния, одно на другое, при использовании
паттерна State - вам поможет например паттерн Strategy.

P.S. Паттерн Strategy примерно в 5 раз проще понять, чем паттерн Singleton.
Доберитесь до примера кода в паттерне Strategy - в три секунды разберетесь по нему.

Daniil Tutubalin

unread,
Jan 20, 2009, 9:24:23 AM1/20/09
to ruF...@googlegroups.com
> А в чем проблема? x += (targetX - x) / 20 на ENTER_FRAME, например :-)
> targetX = текущее значение из модели.

Вот именно с такой формулой у меня было больше всего багов :)
Например, значение 499 (вместо требуемых 500) может провесеть на
экране очень долго.
Поэтому после нескольких шагов нужно округлить в большую сторону.
Но если у нас очки наоборот уменьшались, то из-за этого округления у
нас может получиться 501.

Denis Kolyako

unread,
Jan 20, 2009, 9:36:22 AM1/20/09
to Daniil Tutubalin
Здравствуйте, Daniil.

> Поэтому после нескольких шагов нужно округлить в большую сторону.

Ничего не мешает плюсовать какой-нибудь dx, а результатом показывать
round от dx.

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

Опять же, это конкретная реализация вьювера, модель тут никакого
участия, кроме как выдачи текущего значения, не принимает.

Daniil Tutubalin

unread,
Jan 20, 2009, 9:38:03 AM1/20/09
to ruF...@googlegroups.com

Иногда отображение данных из модели требует некоторого времени,
нескольких кадров.
А мы хотим показать пользователю сразу готовый результат. Поэтому
готовим объект off-screen, а когда готов - показываем.

Другой случай - визуальный объект вообще никогда не попадёт на сцену.
Но тем не менее будет отображён :)
Например, операции с битмапами позволяют создавать очень интересные
спецэффекты. Но bitmapData не имеет:
- свойства graphics - мы не можем рисовать на нём примитивы (кроме
прямоугольничков и точек);
- детей - мы не можем просто так впихнуть в него, скажем, TextField,
можно только нарисовать с помощью draw;
- кадров - мы не можем сказать ему play(), чтобы он сам собой менялся.

Поэтому иногда приходится делать off-screen визуальные объекты (Shape,
TextField, MovieClip, Sprite), которые никогда не будут добавлены в
display list, но тем не могут зависить от модели, менять свой внешний
вид и, как ни странно, отображаться на экране.

Дмитрий Пилипенко

unread,
Jan 20, 2009, 9:39:51 AM1/20/09
to ruF...@googlegroups.com
Привет Данил,

Но если у нас очки наоборот уменьшались, то из-за этого округления у
нас может получиться 501.
  
Но если у нас очки уменьшаются, то округляем в меньшую сторону. Math.floor(x) из-за этого округления у нас может получиться 500.
--
With regards, Dmytro Pilipenko =).

andrey Vichodcev

unread,
Jan 20, 2009, 9:51:19 AM1/20/09
to ruF...@googlegroups.com
­X-No-Archive: yes
Daniil Tutubalin
извини, еще раз, но создание всяких визуальных эффектов конечно интересная тема, но не особо помогающая понять MVC.

Daniil Tutubalin

unread,
Jan 20, 2009, 9:55:48 AM1/20/09
to ruF...@googlegroups.com
> Ничего не мешает плюсовать какой-нибудь dx, а результатом показывать
> round от dx.
> Если дельта меньше 1, то можно прекратить подводить значение и
> вывести вполне конкретное.

Можно. Но выглядеть это будет неравномерно.
Например, показания индикатора могут быть такими: 493, 494, 495, бух!,
500 (dx стало меньше 1).
Игроки может и не заметят, а вот QA обязательно придеруться.

> Опять же, это конкретная реализация вьювера, модель тут никакого
> участия, кроме как выдачи текущего значения, не принимает.

Это я привёл простейший пример, когда View отображает неактуальные
значения в Model.
Просто мне кажется, что использование MVC оправдано только в неигровых
приложениях, где View моментально отображает изменения модели.
Изменился список - обновили List. Пришли новые числа - показали сразу.
В игровых приложениях, где View частенько должен слегка отставать от
Model, MVC только всё усложняет.

Daniil Tutubalin

unread,
Jan 20, 2009, 10:05:39 AM1/20/09
to ruF...@googlegroups.com
> извини, еще раз, но создание всяких визуальных эффектов конечно интересная тема, но не особо помогающая понять MVC.

Я просто говорю о том, что root - это не лучшее место для хранения
модели. В том числе опровергаю такой аргумент как "зато каждый
DisplayObject будет иметь ссылку".
Хотя это и не главное.

Посмотри например движок box2d (флешовый порт). Там все физические
объекты являются невизуальными. Они не связаны ни с DisplayObject, ни
уж тем более с root.
Ты сам решаешь, как их отобразить - сделать отдельный спрайт для
каждого объекта или просто рисовать их через moveTo, lineTo,
drawEllipse и т.д.
Вот именно так я себе и представляю модель. В данном случае - физическую модель.

Denis Kolyako

unread,
Jan 20, 2009, 10:09:25 AM1/20/09
to Daniil Tutubalin
Здравствуйте, Daniil.

> Например, показания индикатора могут быть такими: 493, 494, 495, бух!,
> 500 (dx стало меньше 1).

Не dx, а разница (дельта) между targetX и dx. Если будет 495, то дельта будет
равна 5 плюс-минус совсем уж мелочи. Но никак не меньше единицы.

> Игроки может и не заметят, а вот QA обязательно придеруться.

Ну а MVC-то каким тут боком? Один фиг, нужно добираться до
конкретного значения. Получено оно из модели или ещё откуда —
неважно. Вьювер должен показать то, что его просят, а не 500 и
плюс-минус пару десятков, сколько насчиталось.

> В игровых приложениях, где View частенько должен слегка отставать от
> Model, MVC только всё усложняет.

Не знаю, не вижу усложнения. В том же Flex framework слайдер при
клике по треку гоняет ползунок туда-сюда, но значение в конце-концов
вполне конкретное.

Ivan Dembicki

unread,
Jan 20, 2009, 10:26:27 AM1/20/09
to ruF...@googlegroups.com
Hello,

>> В игровых приложениях, где View частенько должен слегка отставать от
>> Model, MVC только всё усложняет.

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

Daniil Tutubalin

unread,
Jan 20, 2009, 10:53:27 AM1/20/09
to ruF...@googlegroups.com
> - возможно, ты имеешь ввиду очередь.

Да именно.
Но вот для меня пока остаётся загадкой, где должна быть реализована
очередь: в M, в V или может в C?

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

Если реализовать очередь в модели. Получается, что модель "прогнулась"
под представление. Т.е. структура модели (наличие очереди изменений)
обусловлена спецификой представления (его заторможенностью).
Нарушается принцип о независимости модели от представления.

И ещё, что меня частенько напрягает в MVC - это необходимость
дублирования данных, иногда вплоть до одинаковых свойств.
Например свойство balance у модели (актуальный баланс) и свойство
баланс у представления (отображаемый баланс).

Ivan Dembicki

unread,
Jan 20, 2009, 11:07:02 AM1/20/09
to ruF...@googlegroups.com
Hello Daniil,

> С одной стороны логично сделать в представлении.

- логично сделать отдельным классом, но всё равно,
в модели MVC, конвеер принадлежит представлению
и неразрывно с ним связан.

> Если реализовать очередь в модели.

- нельзя точно.

Андрей Скорик

unread,
Jan 20, 2009, 7:08:37 PM1/20/09
to ruF...@googlegroups.com
Затем Представление №2 - игровой стол со ставками - должен плавненько
переместить чипы, выигрывшие - в одну стороны, проигравшие - в другую.
И только после всего этого Представление №3 - индикатор баланса -
должен отобразить новый баланс.

Как это реализуется в MVC?

А как в жизни:

1. "директор: что-то мне как то не по себе...но надо! Таня, зайди!" (контроллер поместил  данные в модель)
2. "Таня: все, друзья, халявных обедов больше не будет.". (модель данные приняла, возможно перераспределила по другим своим свойствам и тд.. диспатчит события)
3. "девелопер: А кушать-то хочется. Свалить что-ли?" (вид получил оповещение о том что его данные "устарели")
3. "девелопер: Надо прикинуть. позвонить Толяну.. давно звал.."  ( вид запустил свои собственные механизмы адаптации  - :) ну покрутил рулетку. как закончил оповестил.)
4. "директор: Так.. в связи с мировым экономическим.. Короче.. Ты уволен!" (контролер сменил текущий активный вид, поползли наши фишки)
5. "девелопер: Ну и идите на ..!!! Еще я без обеда не работал!" (Вид отписался от всего, "прибрался на рабочем месте" и гордо удалился)

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

И модели и контроллеру глубоко пофиг на эти вещи.

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

Меня больше вот такой вопрос интересовал... если допустим мы имеем достаточно интенсивный процесс изменения вида... А надо ли каждый раз при этом дергать контроллер? Может быть имеет смысл делать некий буфер... и отдавать данные разово.. (ну не знаю таймер, заполнение массива и тд)
Ну то есть научить вид немножко разбираться в ситуации..
Как это с точки зрения производительности и "правильности"? Сколько автономии давать республикам, чтобы они не захотели отделиться? Не перестали слушаться столицы?
--
С уважением, Скорик Андрей. andrew...@gmail.com

Андрей Скорик

unread,
Jan 20, 2009, 7:17:02 PM1/20/09
to ruF...@googlegroups.com
 (контролер сменил текущий активный вид, поползли наши фишки)

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

:) отдел кадров короче.

andrey Vichodcev

unread,
Jan 21, 2009, 3:48:23 AM1/21/09
to ruF...@googlegroups.com

Меня больше вот такой вопрос интересовал... если допустим мы имеем достаточно интенсивный процесс изменения вида... А надо ли каждый раз при этом дергать контроллер? Может быть имеет смысл делать некий буфер... и отдавать данные разово.. (ну не знаю таймер, заполнение массива и тд)
Ну то есть научить вид немножко разбираться в ситуации..
Как это с точки зрения производительности и "правильности"? Сколько автономии давать республикам, чтобы они не захотели отделиться? Не перестали слушаться столицы?
представление само генерит события для контроллера. а когда оно это делает и делает ли вообще.
ну например нам надо отловить даблклик. я думаю что представление само отслеживает нажатия, и если выявляет дабклик оповещает об этом контроллер. а не при каждом клике кричит контроллеру "в меня кликнули - прими решение".
по логике так.
Reply all
Reply to author
Forward
0 new messages