Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 22.02.2018, 22:48
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 41  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
dimarik,вот по твоему опыту на сервер данные слать должна модель?Тут несколько раз возникала идея что это работа для контроллера.По мне так контроллеру вовсе незачем знать кухню модели и протокол общения с сервером.
Вики говорит, что можно и так и так,но предостерегает от «ТТУК» («Толстые, тупые, уродливые контроллеры»; Fat Stupid Ugly Controllers).Интересует твое мнение по вопросу.

Старый 22.02.2018, 23:22
dimarik вне форума Посмотреть профиль Отправить личное сообщение для dimarik Найти все сообщения от dimarik
  № 42  
Ответить с цитированием
dimarik
.
 
Аватар для dimarik

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
undefined, дружище, пожалуйста, прекращай троллить ).
__________________
Воспитан в TimeZero. Работаю в Mail.ru.

Старый 27.02.2018, 16:41
in4core вне форума Посмотреть профиль Отправить личное сообщение для in4core Найти все сообщения от in4core
  № 43  
Ответить с цитированием
in4core
[+4 06.05.14]
 
Аватар для in4core

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
dimarik - моя трактовка вполне как раз нормальна. Ты забываешься, что проекты разные, и каждый работает с разными приложениями и играми. В твоем случае - модель может быть ГЛАВОЙ приложения ( в твоем случае, всмысле в твоих проектах) , в более простых же проектах, модель обычно коробка данных. - Давай рассмтрим простой пример пинг-понга скажем. 2 дощечки и шарик. Вьюха хватает события мыши(клавы) и т.п. проверяет на хитТест попадание шарика, диспатчит ГОЛ, контроллер ловит событие и запускает процесс в моделе типа ГОЛ++. В данной игре кроме как счетчик голов, счетчик SCORE и т.п. в моделе ничего не будет, и да это будет безмозглая коробка данных. Это если по простому, можно конечно начать изврат = и делать модель завязанную на всю логику, в таком простом приложении, это называется too much
По топик стартеру - задавая такие вопросы, которые он задает, рано лезть и писать ММО, а значит ему пока надо научится на простых проектах. Сразу лезть в дебри и настроить себе голову так, что модель это основа - сможет только бывалый, вспомни как ты начинал, у тебя и мыслей таких не было.

undefined - учитесь оптимизировать приложения. Если ваш контроллер становится толстым, значит подход неверный. У меня обычно контроллер( base ) кроме как запросы к серверу и получения данных ( + работа с моделью соответсвенно) ничего не делает, в крайнем случае можно дернуть вью из контрола пользуясь MVP - но это обычно ровно столько методов, сколько запросов к серверу. И я опять же не претендую на знание гуру MVC - mvc - он такой, какой тебе надо, а не такой который тебе навязывает то один, то другой, когда голова начинает у некоторых идти кругом.
__________________
Марк Tween

Старый 27.02.2018, 17:23
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 44  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
in4core, не соглашусь. Уже много раз оговаривалось, что модель — это ядро приложения.
В пинг-понге вью передает контроллеру сообщение о том, что что делает игрок (вьюха сама разруливает, каким именно образом игрок воздействует на смену направления и скорости движения палки). Контроллер эту информацию передает модели, мол, там палку в другую сторону потянули. Именно модель определяет, гол или нет. Если да, модель гавкает об изменении счета или о геймовере. Первое ловит сама вью и перерисовывает табло. Второе ловит контроллер и действует согласно заложенному воркфлоу. Он сообщает вьюхе, чтобы она сворачивала игру и разворачивала сообщение, что игрок продул. От нее же контроллер ждет, что там игрок решил: разбить приставку о стену или таки нажать что-то там (контроллеру на это пофиг — это может быть нарисованная кнопка или хоткей) что означает "давай еще раз!!"
__________________
Поймай яблоко 2!

Старый 27.02.2018, 17:41
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 45  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Други! Сидел, читал с интересом дискуссию профи, а пока созрел ещё вопрос по MVC. В моём проекте (по-прежнему, это игра на механике текстового квеста) всё взаимодействие с пользователем строится через последовательно выводимые ему текста и изображения (всякие шкалы и портреты пока не в счёт). Сейчас это работает так: Модель, делая расчёты, набивает в массив инструкции. Каждый элемент - экземпляр класса-наследника ViewInstruction. Когда посылается событие на отработку этих инструкций, Вью начинает его разбирать, вынимая и анализируя каждый элемент массива вот таким образом:

Код AS3:
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;
				}
Уже вижу сам, что подход хреновый. В главной Вью получается мясо из деталей этих инструкций. Хочу реализовать что-то типа паттерна GoF "Стратегия", т.е. реализовать в каждой из инструкций метод типа execute(), чтобы Вьюха, "достав" из массива очередную инструкцию, не разбиралась в нюансах, а просто запускала её. Плюс такой подход позволит добавлять новые возможные инструкции. Но тут возникает вопрос, на который я хотел бы получить мнения знатоков.

Чтобы быть выполненными, экземплярам классов-инструкций требуются на входе какие-то элементы самой главной Вью. Например, инструкция на обновление текста должна получить ссылку на экземпляр MainTextArea и доступ к её пабликам. А инструкции на вывод арта никак не обойтись без ссылки на слой, куда этот арт нужно выводить, плюс какие-то координаты могут потребоваться, которые хранятся в главной Вью. Навскидку, можно было бы запускать из главной вью вот так:

Код AS3:
_currentInstruction.execute(this);
И ваще не париться Но смущает многократно услышанные здесь от компетентных людей рекомендации о недопустимости передачи ссылок на родительские объекты детям и т.п. Собственно, просьба прокомментировать. Спасибо.
__________________
Не сломано - не чини!

Старый 27.02.2018, 17:45
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 46  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
Цитата:
Сообщение от Zebestov Посмотреть сообщение
Первое ловит сама вью и перерисовывает табло. Второе ловит контроллер и действует согласно заложенному воркфлоу. Он сообщает вьюхе, чтобы она сворачивала игру и разворачивала сообщение, что игрок продул.
Почему бы вьюхе не ловить гамовер раз уж в каноническом mvc события от модели слушает только вью?

Старый 27.02.2018, 18:43
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 47  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Цитата:
Сообщение от undefined Посмотреть сообщение
Почему бы вьюхе не ловить гамовер раз уж в каноническом mvc события от модели слушает только вью?
Потому что ходом выполнения приложения заведует контроллер и не вьюхе решать, что будет дальше после того, как игрок проиграл. Это может быть таки геймовер, это может быть rewarded video ради продолжения и такое прочее. Все это рулит контроллер — это практически единственная его работа, направлять ход приложения от пункта к пункту. Дело вьюхи сидеть на попе ровно, рисовать, что скажут, и сообщать, куда там игрок тыцнул.
__________________
Поймай яблоко 2!

Старый 27.02.2018, 18:58
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 48  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
да,резонно

Старый 27.02.2018, 19:37
ZergMaster вне форума Посмотреть профиль Отправить личное сообщение для ZergMaster Найти все сообщения от ZergMaster
  № 49  
Ответить с цитированием
ZergMaster
 
Аватар для ZergMaster

Регистрация: May 2008
Адрес: Питер
Сообщений: 385
Отправить сообщение для ZergMaster с помощью ICQ Отправить сообщение для ZergMaster с помощью Skype™
Это особенно критически важно в монетизированных клиент-серверных приложениях. Когда нужно, чтобы логика добычи денег обсчитывалась в скрытой модели на сервере. Например в игровых автоматах, вьюшка лишь сообщает о кликах по кнопкам, а контроллер обращается к удаленной модели не сервере, та обсчитывает все по формулам конкретной игры и выдает результат. Который и отображает вьюшка, имитируя бурную деятельность.

С другой стороны, ничего не мешает делать модель по типу перфокарты, если безопасности сильно не требуется. Которая является некими изменяемыми данными, которые мы просто отображаем вьюшкой. И разные вью могут эти данные отображать сильно по разному, имея внутри себя всякую свою разнообразную логику, базирующуюся на данных модели.
В общем и целом, соглашусь с in4core - все сильно зависит о задачи.
__________________
while(live()) { hope(); }

Старый 27.02.2018, 21:54
in4core вне форума Посмотреть профиль Отправить личное сообщение для in4core Найти все сообщения от in4core
  № 50  
Ответить с цитированием
in4core
[+4 06.05.14]
 
Аватар для in4core

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
ZergMaster - именно об этом я и писал, слово в слово.

Zebestov - дружище, вот ничем не отличается твой пример собственно от моего, лишь тем, что модель решило гол или не гол. Хотя - даже чисто математически смотри -
if(sharik.x < 0) dispatchEvnet(gol...) model-> aga gol Это я к тому, что я уже на этапе вью знаю гол или нет, нафига мне передавать каждый раз координаты в модель, или же вообще постоянно апдейтить это на таймере в моделе, чтобы модель узнала гол произошел или нет? Что за злобное рпограммирование?

Добавлено через 6 минут
Не надо ничего себе усложнять - мвц - это инстуркции к применению, а не злобный смотритель с палкой. Тут 100500 людей, и большинство тем или иным способом юзает этот паттерн - и 100500%, что у каждого он СВОЙ, просто потому, что каждый пишет так, как ему удобно, НООО - есть большое но, есть конечно и нюансы, где перегибать палку не надо, если ты из view.model.method() делаешь - бить по рукам, а если у тебя gfx логика во вью, а модель только сборщик данных ( как это реально работает в слотах ) , а контроллер общается с сервером и напрямую работает с вью по мвп моделе, это не есть ох и ах, это один из методов организации приложения.
__________________
Марк Tween

Создать новую тему Ответ Часовой пояс GMT +4, время: 13:14.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Теги
MVC , mvo , Проектирование
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 13:14.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.