|
|
|||||
Регистрация: Jan 2012
Сообщений: 836
|
А вот у меня такой вопрос возник. Если например во вьюхе, нужно кликнуть на способность, куда записывать идентификатор этой способности? Чтобы по нажатию кнопки(например "Изучить"), последующий запрос на сервер отправился с этим id. Понятно, что вью не изменяет модель, поэтому модель способности(а именно записать туда кликнутный идентификатор) можно обновить только через контроллер. Что вообще должно отвечать, за запись такого рода вещей? Хотя наверно, для этого надо создать переменную в контроллере, например click_id и если кликнул на способность, получаем её id и записывать в контроллере в click_id, нажали на другую способность, также перезаписываем click_id, а уже отправка на сервер, берем этот самый click_id
|
|
|||||
[+4 06.05.14]
|
И кстати, вот интересный момент : у тебя есть свитчер + -. Когда жмется +, счетчик меняется на ++, минус на -- соответсвенно, и это записывается текстовое поле. Кроме того это значение важно и другим вьюхам, по нему они определяют что делать далее. Тоесть значение счетчика, это переменная модели, глобальной допустим. Все вьюхи подписаны на модель и жаждут изменения счетчика, чтобы делать свои дела.
И вот смотрим : жму я +, по парадигме я должен отправить ивент в контроллер из вью, контроллер доложен дернуть модель, модель должна записать данные - а затем и разослать всем. Это на какой то пук кнопки. А вот если я отойду в неком приложении от этой идеи, и лишь в этом месте дерну модель напрямую как model.plus() - я выходит сразу стану балдой и балбесом, и это нифига не МВС, когда все остальное написано без таких вот изварщений? С другой стороны - мы можем сказать, что значение счетчика может быть не переменной модели, а переменной вью, и тогда вопрос снимается, ты из вьюХ баблишь в главный, а он там всем вьюхам рассылает апдейт, но в этом случае у тебя уже вью работает как модель. Тут тонкая грань - какие процессы будут идти в моделе, а какие во вью... Добавлено через 2 минуты Цитата:
__________________
Марк Tween |
|
|||||
Регистрация: Jan 2012
Сообщений: 836
|
Цитата:
|
|
|||||
.
|
Классический способ реализации метапаттерна MVC описан в вики. Это упрощенная схема работы комплексных (complex — составной) блоков, состоящих из других паттернов. В моей практике все блоки я реализовавал из шаблонов GoF.
От задачи все не сильно зависит, да простит меня камрад in4core... За разработку даже простого пинг-понга я бы не стал браться без моего любимого быстрого инструментария. Обычно я делаю модель на основании технического задания (ТЗ). Никаких вьюх пока еще нет. Как будут выглядеть вьюхи очень слабо представляет себе даже геймдизайнер. И я имею ввиду не только их художественную ценность, а то, что они будут собирать от пользователя. И их либо просто нет, либо кто-то их еще пишет. Зато геймдизайнер обладает формулами и общим видением проекта, чем и делится с разрабом, т. е. мной. Иногда это выглядит как общение на пальцах. И вот, моя модель готова в соответствии с ТЗ и прошла юниттесты. Подтягиваются вьюхи, и приложение собрано и готово себя показать. Приложение может существовать без вью. Они просто заменяются на mock'и. Я рассуждаю о модели в паттерне MVC как о Вселенной: на её физические законы не влияют (но это не точно) наши рассуждения, мнения и вообще наш Homo sapiens разум. Законы природы везде работают одинаково. Законы природы просто есть и они действуют без нашего участия. Неважно в каком диапазоне волн воспринимают визуально мир люди, собаки и кроты. Мы есть только вьюхи в шаблонах Вселенной ). И, кстати, на нас можно давить с помощью Модель в паттерне MVC сама в себе и она самодостаточна. Она получает данные от контроллера, да. И выдает переработанное и осмысленное состояние всем вьюхам, подключенным к этой модели. Если контроллер сказал, что температура за бортом -60°, то модель просто не начнет выращивать курочек для фермы -- слишком холодно. Зато она начнет производство льда в промышленных количествах. По вопросу камрадов Цитата:
Цитата:
Тут нужно пояснение. Данные, находящиеся в модели должны пройти через сериализатор, предназначающийся для конкретной серверной платформы. А возможно и не серверной, если вы просто сохраняете стейт модели в файловую систему. Это существенное дополнение. На самом деле роль сериализаторов и десериализаторов (парсеров) весьма серьёзна. Я видел проект, в котором десериализация данных была в самой модели. Это ставит модель в зависимость от вида внешних данных (JSON, XML, YAML, custom protocol). Не делайте так. Сериализация/десериализация должна быть внешней по отношению к модели и осуществлена с помощью контроллера. Цитата:
Цитата:
Последний раз редактировалось dimarik; 27.02.2018 в 23:20. |
|
|||||
[+4 06.05.14]
|
dimarik - Дим, ну что значит не зависит. Ты рассуждаешь щас и навязываешь, как человек уже покопавшивайся в этом годами, я же тяну другую сторону, я могу с тобой согласится, и скажу - что все что ты говоришь верно, но не надо забываться - что здесь не все люди прошедшие дзен, и могут это осознать сразу, нужны попытки. дела и т.п. *За разработку даже простого пинг-понга я бы не стал браться без моего любимого быстрого инструментария.* это ЩАС ты выпендриваешься, а лет эдак 5-10 назад промолчал бы о своем быстром...хм...инструменте. И про обычно я делаю... мало ли что ты обычно делаешь? Может зубы чистишь. Это сугубо твоя жизненная организация. Ты говоришь каждый раз за СЕБЯ, как делаешь ты - но не объявняешь почему и зачем так делать, это называется я будда и я вам скажу, а почему и как додумывайте сами.
*Обычно я делаю модель на основании технического задания (ТЗ).* ОЛОЛО - даже Ubisoft себе такого не позволят сказать ОБЫЧНО! Ты что создал тонны игр которые весь мир юзает? Чтобы твое обычно было парадигмой? Мало ли что ты делаешь обычно, как бы грубо это не звучало - !
__________________
Марк Tween |
|
|||||
Lorem ipsum
|
ну… т.е. прям таки ничем… ок )
__________________
Поймай яблоко 2! |
|
|||||
[+4 06.05.14]
|
Цитата:
__________________
Марк Tween |
|
|||||
Lorem ipsum
|
Ты не хочешь признавать, что я привел простой пример, который, как и любой сложный пример, базируется на тех же принципах (противоположных тем, что изложил ты). Именно это постоянство от проекта к проекту и делает MVC удобным — ты всегда действуешь одинаково по сути, разница только лишь в масштабе.
__________________
Поймай яблоко 2! |
|
|||||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Есть два столпа на которых держится этот форум – это MVC и in4core.
А ещё проходят года, а dimarik'а читать всё так же увлекательно. Вспомнилось: Цитата:
Цитата:
Всё толстое – плохо. И толстые модели – плохо, и толстые контроллеры – плохо, и толстые стриптизёрши – тоже плохо. В хорошем коде из контроллеров код мигрирует в модель, а из моделей – уже "куда-нибудь". Чаще всего в то, что общим словом называют сервисы. Таскать паттерны Это, к слову, относится и к MVC. В "классическом" MVC вьюха это эдакая чистая функция от модели (моделей). На деле же, в игрульках, вьюха может иметь достаточно обширное внутреннее состояние, ровно до тех пор пока это состояние никак не влияет на общее состояние приложения. Цитата:
Игра без визуального представления вообще (белый экран) бесполезна. CLI App's вполне себе живёт без вьюх (пайпит потоки в stdin/out/err). Вся идея в том, что всё вместе формирует приложение, эти блоки (M/V/C/VM/whatever) по отдельности – самодостаточные элементы (которые просто тестировать – и в этом, в общем-то, добрая половина всего смысла, но о тестах ты только разок упомянул) бесполезны. Цитата:
Цитата:
Сериализатор (который совсем необязательно работает / дёргается с помощью контроллера) читает модель как вью, но вот пишет в неё как контроллер. Или как часть модели. Вью никогда не может просто взять, и поменять все данные внутри модели "сходу". Кто-то другой может. Цитата:
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Регистрация: Oct 2006
Сообщений: 2,281
|
Zebestov:
про вопрос о том,кто должен реагировать на gameover от модели Цитата:
Цитата:
|
Часовой пояс GMT +4, время: 20:36. |
|
« Предыдущая тема | Следующая тема » |
Теги |
MVC , mvo , Проектирование |
|
|