Логика работы MVC

[braun3812]

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

Применяя модель MVC я пишу

public class ModelClass extends EventDispatcher
{
private var objects:Dictionary = new Dictionary();
private var numObjects:Number = 0;

public function ModelClass ()
{

}
public function getObject (id:String) : RoomObject{
//получение объекта по id
return objects[id];
}
public function addObject (obj:RoomObject) {
//добавление объекта в массив объектов
objects[obj.id] = obj;
numObjects++;
trace("Object " + obj.id + " is added");

obj.addEventListener(ModelChange.OBJECT, OnObjectChange);
dispatchEvent(new ModelChange(ModelChange.MODEL));
}
public function OnObjectChange(e:ModelChange) {
//событие изменения модели вызывается при изменении объекта в массиве
dispatchEvent(new ModelChange(ModelChange.MODEL));
}

Описание класса RoomObject не столь важно, у него есть 3 координаты, 3 измерения и ID.
Описание Контроллера

public class ControllerPlain extends EventDispatcher
{

private var model_:ModelClass;
private var view_ :MainPlainView;
private var host_ :DisplayObjectContainer;

public function ControllerPlain(host:DisplayObjectContainer)
{
model_ = new ModelClass();
view_ = new MainPlainView();
model_.addEventListener(ModelChange.MODEL, updateView);
host_ = host;
}
public function renderView() {
//добавление view в display list
if (host_ && view_) {
host_.addChild(view_);
}
}
public function addObject(type:String, pt:MdlCordList, sz:MdlSizeList) {
//метод добавления объекта, который будет непосредственно вызываться
var newObject:RoomObject = new RoomObject();
model_.addObject(newObject);
}
public function updateView () {
//хенлдер события изменения модели
//по сути полная перерисовка view по словарю объектов
for each(var object:RoomObject in model_.objs) {
view_.renderObject(object.id);
}
}

}

}

Надеюсь суть понятна.
Модель и контроллер я построил согласно описанию MVC, которое нашел на этом форуме.
Теперь вопрос

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

Перетаскивание объекта в словаре View -> Событие изменения View -> Обработчик в Контроллере -> Изменение координат объекта в модели -> Событие изменения модели -> Обработчик в контроллере -> Изменение View...

Так вот, как лучше всего оборвать эту "цепочку"? Пока что я могу менять модель только с помощью view путем перетаскивания спрайтов.

То есть в идеале я хочу получить вот что

Перетаскивание объекта в словаре View -> Событие изменения View -> Обработчик в Контроллере -> Изменение координат в модели

Если же мне понадобится изменить сначала модель, а потом view (пока этого не требуется, но потребуется) мне нужна будет такая цепочка событий

Изменение координат объекта в модели -> Событие изменения модели -> Обработчик в контроллере -> Изменение объекта View

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

И второй вопрос, это стоит ли апдейтить модель всю сразу при изменении 1 объекта?

Допустим у меня будет 100 объектов, а перетаскиваю я 1.
В базовом описании модели MVC апдейтится полностью модель, то есть по всем ее параметром она полностью перерисовывается.

Стоит ли написать методы, чтобы можно было апдейтить модель и view соответственно по одному, а не перерисовать весь словарь моих объектов RoomObject ?

[cleptoman]

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

[Babylon]

model_ где вы такой синтаксис узрели при описании MVC?

[cleptoman]

а какое отношение конвенция имеет к сути вопроса? )
хотя , пожалуй , в этом отношении тоже следует подумать/почитать )

[Babylon]

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

[Dukobpa3]

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

[cleptoman]

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

[Babylon]

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

Ответ с сервера совсем не обязательно меняет модель. Если логика на клиенте, т.е. толстый клиент, то логика может разрешать update вида, а может не разрешать, и сама посылать реквесты на сервер.

[AlexCooper]

:D да уж, уже больно смотреть темы про MVC

[cleptoman]

Ответ с сервера совсем не обязательно меняет модель. Если логика на клиенте, т.е. толстый клиент, то логика может разрешать update вида, а может не разрешать, и сама посылать реквесты на сервер.
а вам не кажется, что в модели данные не только по виду могут сидеть? ) потому по ответу логика меняет модель...если это видовые апдейты, то вид их получит..

[Babylon]

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

[Akopalipsis]

я тоже начал познавания mvc на этом форуме и даже вроде с подачи Babylon ,за что ему сто раз спасибо! Но везде минималистические примеры и только недавно тема начала выравниваться в правильное направление. Как гласит MVC - к модели нужно обращаться только в том случаи, если в ней нужно что то поменять. И тут начинается самое сложное, определить что нужно хранить в модели, а что во вью. Если Ваше приложение серверное, то есть нужно отсылать координаты на сервер, то ответ нужно искать в совсем другой стороне. MVC это не совсем патерн, это набор патернов ( наверное штук семи ) и вот только при полном понимании и распределении всех их.

[Babylon]

MVC это паттерн. Просто словом модель подменяют слово логика. А модель это способ организации данных, например коллекция. И коллекций действительно может быть дофига.

[Dukobpa3]

И понеслась.
Толстые Громоздкие Уродливые Контроллеры + Тонкие Тупые Бесполезные Модели.
Модель - это и есть логика. И в этой логике есть данные. И вот эти данные уже как хочь так и храни, хоть каждое поле с сервера дергай.

[Akopalipsis]

MVC это паттерн.
Мультипатерн!)
И если ещё больше конкретизировать, то модель - это движок. Как двигатель на авто, который может и без кузова работать и при чем работать точно так же.

[Babylon]

Про модели вот здесь написано неплохо http://backbonejs.ru/#introduction

Добавлено через 15 минут
Я бы дал такое определение модель для вида это данные, которые можно посылать, изменять видом и принимать для вида. А модель логики (это данные которые можно посылать, изменять логикой и принимать для логики) Как пример- число пулек, жизней и т.д. Как это соотносится с отображением? Правильно - НИКАК! Тоже самое можно сказать и про серверные данные (его модель).

[Akopalipsis]

model_.addEventListener(ModelChange.MODEL, updateView);
Контроллер не должен слушать модель.
public function updateView () {
//хенлдер события изменения модели
//по сути полная перерисовка view по словарю объектов
for each(var object:RoomObject in model_.objs) {
view_.renderObject(object.id);
}
Вот этого тоже не должно быть. Вью должна слушать модель.

[Babylon]

вью должна слушать сервис

[Dukobpa3]

сервис
Сервис - это часть вариации мвц(MVCS), в которую вы почему-то очень сильно верите, но это отнюдь не обязательная часть мвц.

[Babylon]

для игр или для управления умным домом:) у меня другого опыта нет.

Добавлено через 1 минуту
клиентская логика - вешь в чем-то опасная.

[Akopalipsis]

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

[Babylon]

Суть и цель MVC во взаимозаменяемости частей. Даже если эти части исповедуют одно ядро.
Уберите логику с клиента и перенесите на сервер - все по-прежнему должно работать. Или измените вид. Или модель. Как то так.

[Wolsh]

Akopalipsis, я со всем уважением советую Вам еще раз: возьмитесь сделать простой, но конкретный проект. Есть замечательный пример: игра "Пятнашки". Ее можно реализовать без MVC на двух-трех классах (без меню и прочих брюликов). Она не отправит Вас в творческий отпуск на несколько месяцев. Сделайте пятнашки на MVC. Это поможет Вам спокойно в полном осознании пощупать собственными извилинами все базовые аспекты MVC. Если же Вы считаете ниже своего достоинства тратить время на такую "простую" вещь, Вы потратите гораздо больше времени на размышления в вакууме о пулях, крыльях и общении с сервером. Размышлениях, которые не приводят ни к какому реальному пониманию, ибо это не более чем фантазии. Только когда начинаешь писать слова в тексте класса, можно почуствовать реальное мясо кода и увидеть, что куда завязано, чего не хватает и какие связи избыточны. Напишите MVC-пятнашки. А потом привяжите к ним все стандартное игровое оборудование — меню, паузу, рестарт, таймер и т.п. Забудьте пока про сервер, он расщепляет все Ваше понимание. Разберитесь с самой триадой MVC. Это как прыжок с парашютом — пока не прыгнете, Вы не парашютист, сколько бы часов ни просидели в библиотеке, представляя свой полет.

[Akopalipsis]

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

[Dukobpa3]

Если ты не начал что-то делать в течении 72 часов с того момента как решил это делать - ты этого уже никогда не сделаешь.

[Babylon]

Akopalipsis,вью ничем не управляет - вью это текущее отображение вашего геймплея.
Если враг лишил жизни вашего героя, пересекая мувиклипом с мечом, мувиклип с телом героя, вы должны об этом сообщить. Но вот кому сначала модели или сервису? Я думаю сервису, который раздаст это визуальное состояние другим юзерам. А уже затем, логика получив это состояние примет решение о том, что Game Over и опять же сообщит об этом сервису и только потом сервис отобразит состояние GameOver во вью. Как то так.

[Akopalipsis]

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

[Wolsh]

Именно поэтому и советую начать не с РПГ с открытым миром и свободным крафтингом итемов))) Чем проще, тем меньше разнообразие вариантов, которое [обычно] приводит к тому, что страсть перегорает и проект уходит в стол. Амбицией должно быть — научиться, а не выпендриться!)))

[in4core]

Wolsh - при всем моем уважении, не соглашусь - как раз амбиция выпендриться - приводит к результатам. Человек - сам по себе не закоден на ЖЕЛАНИЕ обучаться, его просто может и не быть - а вот желание выпендриться есть у всех и оно бесспорно встает на первое место.

[alexcon314]

Золотые слова :D:D:D.

[Wolsh]

in4core, прямо как в поговорке
— Каша с маслом вкусно!
— Нет! Каша без масла — не вкусно!
Именно потому, что желание выпендриться стоит на первом месте и потому, что "человек не закоден на желание обучаться", мне и приходится напрягать пальцы и печатать эти слова: "амбицией ДОЛЖНО быть желание научиться". Потому что желание выпендриться, безусловно, есть у всех. Стандартом первого сообщения новичка на форуме давно стало "Всем привет! Не пинайте сильно, я только три дня как изучаю флешь и акционШрифт, и у меня сразу возникли вопросы!!!11 Начал писать многопользовательскую РПГ с элементами шутера но не знаю в каком кадре лучше создать первую партию из 16 миллионов монстров и как лучше хранить их имена? Не будет ли праграмма долго грузиться, если создавать их в первом кадри?"
Обычно через три дня такой геймдевелопер пропадает и появляется снова года через три с вопросом, как нарисовать прямоугольник и добавить его на сцену. И это правильно. ЭТО приводит к результатам.

[alexcon314]

MVC для кэпов:):
M - учеба
V - выпендреж
C - опыт

[Psycho Tiger]

MVC для кэпов:):
M - учеба
V - выпендреж
C - опыт
Почему именно в таком соответствии? )

Wolsh - при всем моем уважении, не соглашусь - как раз амбиция выпендриться - приводит к результатам. Человек - сам по себе не закоден на ЖЕЛАНИЕ обучаться, его просто может и не быть - а вот желание выпендриться есть у всех и оно бесспорно встает на первое место.
Всплакнул.

[Babylon]

Надо ставить перед собой такие цели, которые в состоянии достичь. Конечно всем хочется иметь в портфеле РПГ, но это требует больших усилий и возможно даже ни одного человека, пусть даже такого талантливого как ин4кор. Для этого и существуют компании из людей- кодеров, дизайнеров, планировщиков. Это удобно. Главное, чтобы квалификация была соответствующая.

[Psycho Tiger]

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

[Dukobpa3]

Всплакнул.
Третий день плачу:) Всё никак не отпустит:)

Пойду пилить рпг с мильенами монстров в первом кадре.

[Akopalipsis]

Вопрос к опытным - Вы пользуетесь конструкторами для передачи ссылок?

[Psycho Tiger]

Да. И не только в AS3.

[Dukobpa3]

Ничего плохого нет в передаче в конструктор чего угодно.
Главное чтоб параметров конструктора было не больше 1-3, иначе потом будешь сам путаться и плеваться.

[Akopalipsis]

Psycho Tiger Спасибо! И ещё вопрос к Вам - Вы когда третью часть сделаете?)
Очень хотелось бы видеть работу на настоящем примере. Хотя бы на игре галактика, в котором есть несколько моделей ( стартовое меню, игра ) и так же со вью. Видеть работу остальных шаблонов в действии ( как построен вызов инициализации и удаления ). Вот что такое. И спасибо Вам за прошлые две части!

[Psycho Tiger]

Мой взгляд на всё программирование в целом сильно изменился за это время, поэтому третья часть будет сильно отличаться от первых двух :D
Когда-нибудь ...

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

[Akopalipsis]

Psycho Tiger С наступающим! И жду с нетерпением!

[Babylon]

Dukobpa3, передавайте ссылку на Object, а в нём нужные данные {,,,}

[Psycho Tiger]

Dukobpa3, передавайте ссылку на Object, а в нём нужные данные {,,,}
Давайте лучше XML. А данные – в его нодах.

[Dukobpa3]

И контроллеры в <![CDATA[...]]>

[Babylon]

Давайте лучше XML. А данные – в его нодах.
Я так и делаю.