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

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

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 28.02.2018, 13:53
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 61  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

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

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

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
Цитата:
События, влияющие на ход работы приложения от пункта к пункту, слушает контроллер.
Вот ты объясни человеку о чем ты говоришь на примере. Какие события слушает вью это и так всем понятно. А вот что значит от ПУНКТА к ПУНКТУ. Давай построим простейший пример, чтобы всем было понятно о чем ты пишешь. Как минимум вот на твоей же и игре в подписи.
а) сколько у тебя контроллеров или он один?
б) сколько у тебя моделей? ( если ли общая модель, или же просто разрозненные типа PlayerModel, IFaceModel и т.п. )
в) Что у тебя происходит в иерархии событий и т.п. когда игрок движется вправо-влево, что происходит , когда ловит яблоко?

Я как обычно не претендую на гуру, но как по мне в данной игре достаточно всю логику спокойно уместить во вью, а контроллером только посылать на сервер скоре игрока и т.п. , а модели чисто хранить какие то данные, ну и совсем малость где, обновлять вьюху, но это прям 1-2 метода не более.
__________________
Марк Tween

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

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Контроллеров несколько, дерево.
Моделей несколько, тоже дерево.
Вьюх тоже несколько, и да, опять дерево.
Главный контроллер проводит игру по кругу: меню-игра-меню-игра… "от пункта к пункту".
Контроллер слушает свою модель и свои контроллеры. Например MainController ждет от MainMenuController событие "CLOSE". Дождался — приложение идет дальше — GameController.open(), предварительно подписавшись на его CLOSE. Тот же GameController в свою очередь слушает от GameModel событие GAME_OVER и решает, что делать дальше, после того, как персонаж "запаркуется" на стартовой позиции (тоже по событию от модели поймет): откатать рекламу, например, или сразу посылать событие CLOSE, чтобы MainController снова открыл меню. Таким образом контроллер(ы) заведуют движением приложения.

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

Вправо-влево, генерация яблок, падение яблок (формула равноускоренного падения, привязанная ко времени), фиксация улова, когда яблоко ниже уровня корзины (формула, реализующая фиксацию улова не в данный момент, а тогда, когда яблоко пересекло линию, так мы устраняем эффект от лагов) — все это происходит в модели.

Кроме отображения информации, важной для игры GameView делает еще вещи, которые вообще не должны волновать ни модель, ни кого-либо другого: анимирует появление яблока из листвы, топает ножками персонажа и т.д.

Ну вот условно так.
__________________
Поймай яблоко 2!

Старый 28.02.2018, 15:42
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 64  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
мне кажется zebestov достаточно ясно разделил:событие запускает дальнейший флоу?Да - ловим его в контроллере,нет(типа надо просто обновить очки) - ловим во вью.

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

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Цитата:
Сообщение от undefined Посмотреть сообщение
Dimarik:
Цитата:
Не делайте так. Сериализация/десериализация должна быть внешней по отношению к модели и осуществлена с помощью контроллера.
Выходит что события модели слушает контроллер и дергает нужные вью.Когда тогда вью должна(и должна ли) слушать модель?
Модель работает с данными. Данные приходят извне. Можно использовать подход, когда в модели есть свой механизм Serialize/Deserialize, заточенный на конкретный протокол данных, который целиком передается этому механизму, но это не очень хорошо, потому что ее невозможно без переделок использовать в другом окружении. А можно внешним, легкозаменяемым десериализатором распарсить данные и скормить модели через сеттеры, например. Короче встроенный в модель десериализатор не так удобен.

Добавлено через 10 минут
Цитата:
Сообщение от in4core Посмотреть сообщение
И вот смотрим : жму я +, по парадигме я должен отправить ивент в контроллер из вью, контроллер доложен дернуть модель, модель должна записать данные - а затем и разослать всем. Это на какой то пук кнопки. А вот если я отойду в неком приложении от этой идеи, и лишь в этом месте дерну модель напрямую как model.plus() - я выходит сразу стану балдой и балбесом, и это нифига не МВС, когда все остальное написано без таких вот изварщений?
Могут быть условия, при которых нельзя делать model.plus(). И контроллер знает об этом, а вью — не должна в принципе. В данном случае контроллер реализует паттерн "Посредник". Поэтому все нормально в парадигме.

Добавлено через 17 минут
Цитата:
Сообщение от Psycho Tiger Посмотреть сообщение
Так рад видеть тебя снова
Такая же фигня, братюня )
__________________
Воспитан в TimeZero. Работаю в Mail.ru.

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

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
Дима
Цитата:
Могут быть условия, при которых нельзя делать model.plus(). И контроллер знает об этом, а вью — не должна в принципе. В данном случае контроллер реализует паттерн "Посредник". Поэтому все нормально в парадигме.
Тут двоякое ощущение от твоего ответа. Во-первых, что значит могут быть условия? Вот я например один реализовал приложение, и я знаю, что нет таких условий, и только там где надо я это сделаю например. Во-вторых даже если это будет скажем приложение написанное командой, то никто не мешает вставить * коммент о том, что больше нигде так не делать. - ну это конечно понятно, что правила хорошего тона, и в этом случае все таки нельзя.
А двоякое ощущение, потому что ты пишешь слегка непонятно, *все нормально в парадигме* - это значит ты не запрещаешь раз в 100 лет дернуть метод модели из вью? Или ты говоришь наоборот, что парадигма должна быть выполнена как положено, клик вью, пересылка в контрол, пересылка в модель, рассылка всем ???

Добавлено через 1 минуту
Цитата:
Такая же фигня, братюня )
Да я тут проездом) Просто скучно стало. Скоро убегу опять, на пару лет)
__________________
Марк Tween

Старый 01.03.2018, 00:22
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 67  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
Цитата:
Сообщение от dimarik Посмотреть сообщение
Модель работает с данными. Данные приходят извне. Можно использовать подход, когда в модели есть свой механизм Serialize/Deserialize, заточенный на конкретный протокол данных, который целиком передается этому механизму, но это не очень хорошо, потому что ее невозможно без переделок использовать в другом окружении. А можно внешним, легкозаменяемым десериализатором распарсить данные и скормить модели через сеттеры, например. Короче встроенный в модель десериализатор не так удобен
А что подразумевается под Serialize/Deserialize? Парсинг запроса/ответа в json/строку? Так такое обычно отдается serverManager'у, который сериализует реквест в стринг, шлет на серв,получает респонс и кастует его к ожидаемому типу. Как иначе то?

Старый 01.03.2018, 11:29
Psycho Tiger вне форума Посмотреть профиль Отправить личное сообщение для Psycho Tiger Найти все сообщения от Psycho Tiger
  № 68  
Ответить с цитированием
Psycho Tiger
 
Аватар для Psycho Tiger

блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
Цитата:
Сообщение от undefined Посмотреть сообщение
А что подразумевается под Serialize/Deserialize? Парсинг запроса/ответа в json/строку? Так такое обычно отдается serverManager'у, который сериализует реквест в стринг, шлет на серв,получает респонс и кастует его к ожидаемому типу. Как иначе то?
Бывает, люди пихают всю сериализацию в модель напрямую (т.е. в базовом классе модели объявляют serialize/deserialize, где и вызывается условный `JSON.parse`).
Имеется ввиду, что самый ок вариант – это когда есть условный `ISerializator`, который всем этим и занимается. Весь код приложения к нему, по большей части, агностичен.
Юзкейс: проверять доступность транспорта до тех пор, пока не найдется лучший.
Например: используем [веб]-сокеты, если клиент/платформа может в них. Если нет, то long-polling (это когда HTTP request висит в "ожидании" до тех пор, пока данные не пришли). В первом случае сериализуем в бинарном виде компактненько, во втором – только жирно строками (json/base64/xml/etc).
(Конечно, юзкейз требует ещё и `IServerConnector`, которых тоже два – слать в сокет и слать хттп реквесты – суть та же самая)

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

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Разъяснил как мог:

Цитата:
Сообщение от undefined Посмотреть сообщение
А что подразумевается под Serialize/Deserialize? Парсинг запроса/ответа в json/строку? Так такое обычно отдается serverManager'у, который сериализует реквест в стринг, шлет на серв,получает респонс и кастует его к ожидаемому типу. Как иначе то?
Ну, кастовать Object к ожидаемому типу, если ожидаемый тип конкретнее, чем Object, скорее всего, не получится. Как говорится "Мы кастовали, кастовали, да не выкастовывавали".

Десериализация — процесс перевода последовательности битов в структуру данных (via wikipedia). Парсинг, а точнее, синтаксически анализ, это и есть часть процесса десериализации.

В случае, если модель будет работать с JSON, то произойдет такая цепочка (вариант 1):
1. Чтение из источника потока байтов (файловая система или сетевой протокол), представляющих собою plain текст, который полностью подчиняется грамматике JSON;
2. Преобразование текста (десериализация и парсинг) в ActionScript Object;
3. Чтение полей из этого Object и заполнение полей конкретного объекта(ов) модели.

Второй пункт часто избыточен, поэтому десериализацию можно сделать без него (вариант 2):
1. Чтение из источника потока байтов (файловая система или сетевой протокол), представляющих собою кастомный протокол;
2. Поток по неким правилам анализируется десериализатором, который пишет в поля конкретного объекта(ов) модели.

Пример: есть протокол AMF1/3, с помощью которого происходит десериализация данных непосредственно в strong typed объект ActionScript. Однако с помощью него нельзя переписать поля существующего объекта. Десериализация потока этого протокола средствами флеша всегда приводит к созданию новых объектов.

Так вот десериализатор из второго пункта "варианта 2" может быть:
а) встроен в объекты модели;
б) внешним по отношению к объектам модели.

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

Пункт "б" предпочтительнее. Некто извлекает из модели объект и сам пишет в него. Затем повторяет.

Этот некто и есть десериализатор, зависящий от конкретного протокола. Именно в нем заложены правила разбора протокола.
__________________
Воспитан в TimeZero. Работаю в Mail.ru.


Последний раз редактировалось dimarik; 01.03.2018 в 22:01.
Старый 01.03.2018, 22:05
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 70  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
и это все лишь бы не создавать новый объект на каждый респонс?Оно того не стоит имхо.

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

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

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

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


 


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


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