|
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
dimarik,вот по твоему опыту на сервер данные слать должна модель?Тут несколько раз возникала идея что это работа для контроллера.По мне так контроллеру вовсе незачем знать кухню модели и протокол общения с сервером.
Вики говорит, что можно и так и так,но предостерегает от «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers).Интересует твое мнение по вопросу. |
|
|||||
[+4 06.05.14]
|
dimarik - моя трактовка вполне как раз нормальна. Ты забываешься, что проекты разные, и каждый работает с разными приложениями и играми. В твоем случае - модель может быть ГЛАВОЙ приложения ( в твоем случае, всмысле в твоих проектах) , в более простых же проектах, модель обычно коробка данных. - Давай рассмтрим простой пример пинг-понга скажем. 2 дощечки и шарик. Вьюха хватает события мыши(клавы) и т.п. проверяет на хитТест попадание шарика, диспатчит ГОЛ, контроллер ловит событие и запускает процесс в моделе типа ГОЛ++. В данной игре кроме как счетчик голов, счетчик SCORE и т.п. в моделе ничего не будет, и да это будет безмозглая коробка данных. Это если по простому, можно конечно начать изврат = и делать модель завязанную на всю логику, в таком простом приложении, это называется too much
По топик стартеру - задавая такие вопросы, которые он задает, рано лезть и писать ММО, а значит ему пока надо научится на простых проектах. Сразу лезть в дебри и настроить себе голову так, что модель это основа - сможет только бывалый, вспомни как ты начинал, у тебя и мыслей таких не было. undefined - учитесь оптимизировать приложения. Если ваш контроллер становится толстым, значит подход неверный. У меня обычно контроллер( base ) кроме как запросы к серверу и получения данных ( + работа с моделью соответсвенно) ничего не делает, в крайнем случае можно дернуть вью из контрола пользуясь MVP - но это обычно ровно столько методов, сколько запросов к серверу. И я опять же не претендую на знание гуру MVC - mvc - он такой, какой тебе надо, а не такой который тебе навязывает то один, то другой, когда голова начинает у некоторых идти кругом.
__________________
Марк Tween |
|
|||||
Lorem ipsum
|
in4core, не соглашусь. Уже много раз оговаривалось, что модель — это ядро приложения.
В пинг-понге вью передает контроллеру сообщение о том, что что делает игрок (вьюха сама разруливает, каким именно образом игрок воздействует на смену направления и скорости движения палки). Контроллер эту информацию передает модели, мол, там палку в другую сторону потянули. Именно модель определяет, гол или нет. Если да, модель гавкает об изменении счета или о геймовере. Первое ловит сама вью и перерисовывает табло. Второе ловит контроллер и действует согласно заложенному воркфлоу. Он сообщает вьюхе, чтобы она сворачивала игру и разворачивала сообщение, что игрок продул. От нее же контроллер ждет, что там игрок решил: разбить приставку о стену или таки нажать что-то там (контроллеру на это пофиг — это может быть нарисованная кнопка или хоткей) что означает "давай еще раз!!"
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Други! Сидел, читал с интересом дискуссию профи, а пока созрел ещё вопрос по MVC. В моём проекте (по-прежнему, это игра на механике текстового квеста) всё взаимодействие с пользователем строится через последовательно выводимые ему текста и изображения (всякие шкалы и портреты пока не в счёт). Сейчас это работает так: Модель, делая расчёты, набивает в массив инструкции. Каждый элемент - экземпляр класса-наследника ViewInstruction. Когда посылается событие на отработку этих инструкций, Вью начинает его разбирать, вынимая и анализируя каждый элемент массива вот таким образом:
private function parseStateArrayBlock(event: Event) : void { if (!_stateArray.length) dispatchEvent(new Event(STATE_ARRAY_PROCESSED)); else { var stateArrayBlock: * = _stateArray.shift(); if (stateArrayBlock is MainTextAreaInstruction) { // Здесь инструкции на вывод текста в дочерний компонент _mainTextArea dispatchEvent(new Event(PARSE_STATE_ARRAY_BLOCK)); return; } else if (stateArrayBlock is BackInstruction) { // Здесь инструкции на вывод арта в слой _layerBack dispatchEvent(new Event(PARSE_STATE_ARRAY_BLOCK)); return; } Чтобы быть выполненными, экземплярам классов-инструкций требуются на входе какие-то элементы самой главной Вью. Например, инструкция на обновление текста должна получить ссылку на экземпляр MainTextArea и доступ к её пабликам. А инструкции на вывод арта никак не обойтись без ссылки на слой, куда этот арт нужно выводить, плюс какие-то координаты могут потребоваться, которые хранятся в главной Вью. Навскидку, можно было бы запускать из главной вью вот так: И ваще не париться Но смущает многократно услышанные здесь от компетентных людей рекомендации о недопустимости передачи ссылок на родительские объекты детям и т.п. Собственно, просьба прокомментировать. Спасибо.
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
Цитата:
|
|
|||||
Lorem ipsum
|
Цитата:
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
да,резонно
|
|
|||||
Это особенно критически важно в монетизированных клиент-серверных приложениях. Когда нужно, чтобы логика добычи денег обсчитывалась в скрытой модели на сервере. Например в игровых автоматах, вьюшка лишь сообщает о кликах по кнопкам, а контроллер обращается к удаленной модели не сервере, та обсчитывает все по формулам конкретной игры и выдает результат. Который и отображает вьюшка, имитируя бурную деятельность.
С другой стороны, ничего не мешает делать модель по типу перфокарты, если безопасности сильно не требуется. Которая является некими изменяемыми данными, которые мы просто отображаем вьюшкой. И разные вью могут эти данные отображать сильно по разному, имея внутри себя всякую свою разнообразную логику, базирующуюся на данных модели. В общем и целом, соглашусь с in4core - все сильно зависит о задачи.
__________________
while(live()) { hope(); } |
|
|||||
[+4 06.05.14]
|
ZergMaster - именно об этом я и писал, слово в слово.
Zebestov - дружище, вот ничем не отличается твой пример собственно от моего, лишь тем, что модель решило гол или не гол. Хотя - даже чисто математически смотри - if(sharik.x < 0) dispatchEvnet(gol...) model-> aga gol Это я к тому, что я уже на этапе вью знаю гол или нет, нафига мне передавать каждый раз координаты в модель, или же вообще постоянно апдейтить это на таймере в моделе, чтобы модель узнала гол произошел или нет? Что за злобное рпограммирование? Добавлено через 6 минут Не надо ничего себе усложнять - мвц - это инстуркции к применению, а не злобный смотритель с палкой. Тут 100500 людей, и большинство тем или иным способом юзает этот паттерн - и 100500%, что у каждого он СВОЙ, просто потому, что каждый пишет так, как ему удобно, НООО - есть большое но, есть конечно и нюансы, где перегибать палку не надо, если ты из view.model.method() делаешь - бить по рукам, а если у тебя gfx логика во вью, а модель только сборщик данных ( как это реально работает в слотах ) , а контроллер общается с сервером и напрямую работает с вью по мвп моделе, это не есть ох и ах, это один из методов организации приложения.
__________________
Марк Tween |
Часовой пояс GMT +4, время: 10:22. |
|
« Предыдущая тема | Следующая тема » |
Теги |
MVC , mvo , Проектирование |
|
|