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

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

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

Регистрация: Jan 2012
Сообщений: 834
А вот у меня такой вопрос возник. Если например во вьюхе, нужно кликнуть на способность, куда записывать идентификатор этой способности? Чтобы по нажатию кнопки(например "Изучить"), последующий запрос на сервер отправился с этим id. Понятно, что вью не изменяет модель, поэтому модель способности(а именно записать туда кликнутный идентификатор) можно обновить только через контроллер. Что вообще должно отвечать, за запись такого рода вещей? Хотя наверно, для этого надо создать переменную в контроллере, например click_id и если кликнул на способность, получаем её id и записывать в контроллере в click_id, нажали на другую способность, также перезаписываем click_id, а уже отправка на сервер, берем этот самый click_id

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

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

Добавлено через 2 минуты
Цитата:
А вот у меня такой вопрос возник. Если например во вьюхе, нужно кликнуть на способность, куда записывать идентификатор этой способности? Чтобы по нажатию кнопки(например "Изучить"), последующий запрос на сервер отправился с этим id. Понятно, что вью не изменяет модель, поэтому модель способности(а именно записать туда кликнутный идентификатор) можно обновить только через контроллер. Что вообще должно отвечать, за запись такого рода вещей?
Клик - это внутреВьюшная фишка. Если приложение реально серьезное, то в этом случае ты должен отправить событие Event.LEARN, id в контроллер, который либо запишет это в модель, если твоя модель есть ядро, а если ядро это сервер, то отдаст на сервер. А уже сервер потом тебе скажет куда тебе идти и что тебе делать, после эьтго клика
__________________
Марк Tween

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

Регистрация: Jan 2012
Сообщений: 834
Цитата:
id в контроллер, который либо запишет это в модель,
А если записать это в сам контроллер?

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

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Классический способ реализации метапаттерна MVC описан в вики. Это упрощенная схема работы комплексных (complex — составной) блоков, состоящих из других паттернов. В моей практике все блоки я реализовавал из шаблонов GoF.

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

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

Я рассуждаю о модели в паттерне MVC как о Вселенной: на её физические законы не влияют (но это не точно) наши рассуждения, мнения и вообще наш Homo sapiens разум. Законы природы везде работают одинаково. Законы природы просто есть и они действуют без нашего участия. Неважно в каком диапазоне волн воспринимают визуально мир люди, собаки и кроты. Мы есть только вьюхи в шаблонах Вселенной ). И, кстати, на нас можно давить с помощью контроллера модели (например, погоды) и мы станем утепляться или, наоборот, постараемся найти прохладу.

Модель в паттерне MVC сама в себе и она самодостаточна. Она получает данные от контроллера, да. И выдает переработанное и осмысленное состояние всем вьюхам, подключенным к этой модели. Если контроллер сказал, что температура за бортом -60°, то модель просто не начнет выращивать курочек для фермы -- слишком холодно. Зато она начнет производство льда в промышленных количествах.

По вопросу камрадов
Цитата:
Сообщение от undefined Посмотреть сообщение
dimarik,вот по твоему опыту на сервер данные слать должна модель?Тут несколько раз возникала идея что это работа для контроллера.По мне так контроллеру вовсе незачем знать кухню модели и протокол общения с сервером.
и
Цитата:
Сообщение от ZergMaster Посмотреть сообщение
Это особенно критически важно в монетизированных клиент-серверных приложениях. Когда нужно, чтобы логика добычи денег обсчитывалась в скрытой модели на сервере. Например в игровых автоматах, вьюшка лишь сообщает о кликах по кнопкам, а контроллер обращается к удаленной модели не сервере, та обсчитывает все по формулам конкретной игры и выдает результат. Который и отображает вьюшка, имитируя бурную деятельность.
Отвечу... Какие данные и в каком виде нужно отсылать серверу должна знать модель. Для модели сервер есть самая обычная вью. Как это ни странно. В картинке из вики вверху поста нет понятия "сервер". Зато есть понятие "view".
Тут нужно пояснение. Данные, находящиеся в модели должны пройти через сериализатор, предназначающийся для конкретной серверной платформы. А возможно и не серверной, если вы просто сохраняете стейт модели в файловую систему. Это существенное дополнение. На самом деле роль сериализаторов и десериализаторов (парсеров) весьма серьёзна. Я видел проект, в котором десериализация данных была в самой модели. Это ставит модель в зависимость от вида внешних данных (JSON, XML, YAML, custom protocol). Не делайте так. Сериализация/десериализация должна быть внешней по отношению к модели и осуществлена с помощью контроллера.

Цитата:
Сообщение от Appleman Посмотреть сообщение
Други! Сидел, читал с интересом дискуссию профи, а пока созрел ещё вопрос по MVC. В моём проекте (по-прежнему, это игра на механике текстового квеста) всё взаимодействие с пользователем строится через последовательно выводимые ему текста и изображения (всякие шкалы и портреты пока не в счёт). Сейчас это работает так: Модель, делая расчёты, набивает в массив инструкции. Каждый элемент - экземпляр класса-наследника ViewInstruction.<skipped>
Тут простое правило, как на картинке вверху поста: у модели нет знания о конкретной реализации механизма вью. Я бы сделал инструкции частью вью и из модели лишь сообщал идентификатор конкретного блока (на самом деле это состояние диалога). Итак, инструкции должны быть в конкретной вью.

Цитата:
Сообщение от undefined Посмотреть сообщение
Почему бы вьюхе не ловить гамовер раз уж в каноническом mvc события от модели слушает только вью?
Холивара немношк. Да, это нормальное явление и модель знает о своем состоянии лучше контроллер(а/ов). Именно она хранит свой стейт и сообщает об его изменении хорошей вьюхе. Камрад Zebestov, наверняка, погорячился. Потому что ходом выполнения приложения заведует модель, а не контроллер. Такая вот «ТТУМ» («Толстая, тупая, уродливая модель»; Fat Stupid Ugly Model). Но это больше шутка. А по-другому на классике не сделаешь.
__________________
Воспитан в TimeZero. Работаю в Mail.ru.


Последний раз редактировалось dimarik; 27.02.2018 в 23:20.
Старый 28.02.2018, 00:26
in4core вне форума Посмотреть профиль Отправить личное сообщение для in4core Найти все сообщения от in4core
  № 55  
Ответить с цитированием
in4core
[+4 06.05.14]
 
Аватар для in4core

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
dimarik - Дим, ну что значит не зависит. Ты рассуждаешь щас и навязываешь, как человек уже покопавшивайся в этом годами, я же тяну другую сторону, я могу с тобой согласится, и скажу - что все что ты говоришь верно, но не надо забываться - что здесь не все люди прошедшие дзен, и могут это осознать сразу, нужны попытки. дела и т.п. *За разработку даже простого пинг-понга я бы не стал браться без моего любимого быстрого инструментария.* это ЩАС ты выпендриваешься, а лет эдак 5-10 назад промолчал бы о своем быстром...хм...инструменте. И про обычно я делаю... мало ли что ты обычно делаешь? Может зубы чистишь. Это сугубо твоя жизненная организация. Ты говоришь каждый раз за СЕБЯ, как делаешь ты - но не объявняешь почему и зачем так делать, это называется я будда и я вам скажу, а почему и как додумывайте сами.
*Обычно я делаю модель на основании технического задания (ТЗ).* ОЛОЛО - даже Ubisoft себе такого не позволят сказать ОБЫЧНО! Ты что создал тонны игр которые весь мир юзает? Чтобы твое обычно было парадигмой? Мало ли что ты делаешь обычно, как бы грубо это не звучало - !
__________________
Марк Tween

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

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Цитата:
Сообщение от in4core Посмотреть сообщение
Zebestov - дружище, вот ничем не отличается твой пример собственно от моего, лишь тем, что модель решило гол или не гол.
ну… т.е. прям таки ничем… ок )
__________________
Поймай яблоко 2!

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

Регистрация: Mar 2009
Сообщений: 4,219
Записей в блоге: 14
Цитата:
ну… т.е. прям таки ничем… ок )
не не я не бухаю, я имею ввиду, что в данной ситуации ( игре ) особо ничем, понимаешь мы говорим на простых примерах - на сложных все совсем подругому и отношение даже другое, вот я о чем.
__________________
Марк Tween

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

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

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

блогер
Регистрация: Jun 2005
Адрес: Новосибирск :D
Сообщений: 6,590
Записей в блоге: 17
Есть два столпа на которых держится этот форум – это MVC и in4core.

А ещё проходят года, а dimarik'а читать всё так же увлекательно. Вспомнилось:
Цитата:
- Чем отличается хороший разработчик от чертовски хорошего разработчика?
- Хороший разработчик может объяснить простые вещи на пальцах, а чертовски хороший сделать то же самое, но не быть при этом мудаком
Цитата:
Такая вот «ТТУМ» («Толстая, тупая, уродливая модель»; Fat Stupid Ugly Model). Но это больше шутка. А по-другому на классике не сделаешь.
Давайте подкину дровишек:
Всё толстое – плохо. И толстые модели – плохо, и толстые контроллеры – плохо, и толстые стриптизёрши – тоже плохо.
В хорошем коде из контроллеров код мигрирует в модель, а из моделей – уже "куда-нибудь". Чаще всего в то, что общим словом называют сервисы.

Таскать паттерны в общем случае это тоже плохо. Паттерны (в том числе GoF'ы, как бы я не любил несколько из них) были придуманы чтобы решать какую-то проблему, которая появляется достаточно часто и достаточно однотипна, чтобы придумать какое-нибудь решение, чтобы оно не раздражало почти всех. Новые языки/фреймворки появляются для того, чтобы попытаться избавиться от старых проблем и постараться не привнести новых. Таскать решения проблем без самих проблем просто по "привычке" не стоит.
Это, к слову, относится и к MVC. В "классическом" MVC вьюха это эдакая чистая функция от модели (моделей). На деле же, в игрульках, вьюха может иметь достаточно обширное внутреннее состояние, ровно до тех пор пока это состояние никак не влияет на общее состояние приложения.

Цитата:
Приложение может существовать без вью. Они просто заменяются на mock'и.
Как и модель может быть замокана/застаблена/зачтоугодно.
Игра без визуального представления вообще (белый экран) бесполезна.
CLI App's вполне себе живёт без вьюх (пайпит потоки в stdin/out/err).
Вся идея в том, что всё вместе формирует приложение, эти блоки (M/V/C/VM/whatever) по отдельности – самодостаточные элементы (которые просто тестировать – и в этом, в общем-то, добрая половина всего смысла, но о тестах ты только разок упомянул) бесполезны.

Цитата:
Какие данные и в каком виде нужно отсылать серверу должна знать модель.
Да
Цитата:
Для модели сервер есть самая обычная вью. Как это ни странно.
Достаточно странно.
Сериализатор (который совсем необязательно работает / дёргается с помощью контроллера) читает модель как вью, но вот пишет в неё как контроллер. Или как часть модели. Вью никогда не может просто взять, и поменять все данные внутри модели "сходу". Кто-то другой может.

Цитата:
*Обычно я делаю модель на основании технического задания (ТЗ).* ОЛОЛО - даже Ubisoft себе такого не позволят сказать ОБЫЧНО! Ты что создал тонны игр которые весь мир юзает? Чтобы твое обычно было парадигмой? Мало ли что ты делаешь обычно, как бы грубо это не звучало - !
Так рад видеть тебя снова

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

Регистрация: Oct 2006
Сообщений: 2,269
Zebestov:
про вопрос о том,кто должен реагировать на gameover от модели
Цитата:
Все это рулит контроллер — это практически единственная его работа, направлять ход приложения от пункта к пункту. Дело вьюхи сидеть на попе ровно, рисовать, что скажут, и сообщать, куда там игрок тыцнул.
Dimarik:
Цитата:
Не делайте так. Сериализация/десериализация должна быть внешней по отношению к модели и осуществлена с помощью контроллера.
Выходит что события модели слушает контроллер и дергает нужные вью.Когда тогда вью должна(и должна ли) слушать модель?

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

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

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

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


 


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


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