Опять MVC - как лучше?
 

Всем привет!

Очень хочу уточнить по поводу проектирования вопрос. Сомневался, куда запихнуть тему - быть может в флейм? Есть у меня некое приложение, построенное, на архитектуре MVC - то есть есть модель, в которой хранятся все данные, по сеттерам происходит некая логика и диспатч об изменениях, которые ловят интересующиеся вьюверы и отображают.
Теперь к конкретике. Допустим, есть у меня машинка. То есть кузов, колеса, все дела. Соответственно - это класс, например, Car. И есть в модели некий параметр усилия, допустим, power, который обозначает кутящий момент двигателя. По нажатии, предположим, пробела, растет power, и когда он преодолевает момент сопротивления (вес машины и т.п.), машина должна начинать движение.
Отсюда вопрос. Как лучше сделать? С одной стороны, с точки зрения ООП, логично, что есть объект машина - со своими свойствами, описанием, функциями. И может быть один-единственный параметр - скорость (которая может быть равна как нулю, так и отрицательным значениям), которую Car считывает из модели и, в связи с этим, уже внутри неё самой происходит куча всякой движухи - крутятся колеса, анимация дыма выхлопной трубы, быть может, даже звуки мотора и т.п. С другой стороны, если скрупулезно придерживаться mvc - обсчитываться должно все в модели - то есть rotation колес, например, положение головки воспроизведения, а viewer должно лишь только отображать и ничего более.
Интересно ваше мнение - как вы считаете делать более правильно? Действительно ли вся логика должна быть в моделях, или, все-таки, приватная логика объектов должна находиться внутри них?

ps: лично мне на данный момент импонирует второй вариант - когда в модели лежат некие главные параметры, а в объектах-вьюверах происходит всякая логика. Мне кажется, это больше отвечает принципу модульности. Или, может быть, такой подход уже есть и называется уже не MVC, а Model-View-Object, например? Или, может, я что-то упускаю?

Забавно. Хотел создать отдельную тему для своих вопросов именно по MVC. Открыл форум, а тему уже ZergMaster создал. :) Поэтому с позволения воспользуюсь и докину ещё своих вопросов для профи.

Нормально ли это, когда вью не просто ждёт событий от модели, а сама ломится в модель, хватает её за какой-нибудь геттер и выдёргивает нужное значение? Поясню на примере. У меня в конструкторе дочернего компонента HeroView сразу выводится имя персонажа, причём это происходит именно в момент создания компонента и больше не меняется на всём протяжении его жизни. Спасибо.

Конечно нормально. Модель для того и предназначена, чтобы предоставлять данные для вьюверов. Соответственно, при создании экземпляра вьювера, поскольку ему передается экземпляр модели, совершенно свободно можно получать разнообразные параметры по get-ам. Вьювер не может изменять, а получать может как угодно. Собственно, есть же два варианта - можно передавать параметры от модели прямо в событиях, а можно по событиям обращаться к имеющемуся экземпляру модели и забирать все,ю что нужно. Мне больше нравится второй вариант.

Модель должна интересоваться только теми данными, которые:
1) сохраняются между запусками приложения (на сервере или на клиенте)
2) непосредственно влияют на другие данные
Другой способ описания гласит: модель хранит ТО, ЧТО отображается, а не ТО, КАК отображается.
Но это описание спорное и скорее концептуальное, чем конкретное. Поскольку эти данные "КАК" очень часто приходится и сохранять в сейвах и использовать в рассчетах (координаты объектов например).

Добавлено через 54 минуты
То, как крутятся колеса, влияет на Результат? Нет? Это Вью.

Крутятся вперед или назад. Очень даже влияет) Это в продолжение к этому
Нет. Игры это вообще особая тема. В них MVC не совсем уместен. Только от части. Данные о стартовых параметрах машины храни непосредственно в её классе, ну или в базовом, если они общие для множества машин. А в модели имеет смысл хранить лишь то, что игрок меняет (прокачивает / устанавливает и т.д.) в виде числовых параметров, если речь идет о показателях машины, или ID предметов, если речь о каких-то зрительных изменениях. Для каждой машины логично хранить свою отдельную запись в базе данных

Крутятся вперед или назад зависит от скорости, которая как раз является безусловно данными Модели. Но Модель не интересует даже наличие или отсутствие колес, и уж тем более — КАК они отображают скорость.

Неверно. Визуальная часть должна отображать происходящее. Вращение колес в твоей системе является декоративным, оно не ВЛИЯЕТ на движение автомобиля, а СЛЕДУЕТ из него. Следовательно модели, как верно заметил Wolsh, нет никакого дела до того, есть ли колеса вообще и как они там должны крутиться.

Друзья, подскажите ещё по MVC, плиз. Не получается по полочкам разложить. Аккурат к вопросу недавно упомянутого "ЧТО" и "КАК" :)

Кейс 1: У персонажа в игре есть есть статусы, т.е. свойства типа Boolean, которые меняют своё значение по ходу игры и оказывают влияние на другие параметры. Типичный пример: состояния персонажа из тактических игр или RPG: кровотечение, отравление, действие заклинаний и т.п. Это, безусловно, данные Модели. При этом некоторые (но не все) статусы должны явно выводится для пользователя в виде иконок. Это прерогатива CharacterView. Проблема следующая. Далеко не все подобные свойства нужно отображать пользователю. Кто должен "знать", какие из них подлежат выводу, а какие носят служебный характер? Мне кажется, что view, но я сомневаюсь.

Кейс 2: по условиям игровой логики, накопление некоего свойства сверх установленного порогового значения открывает новые возможности. Типичная для многих жанров ситуация, когда, например, для проведения каких-то специальных атак требуется энергия или мана выше определённого заранее известного уровня. В модели всё понятно: есть значение порога (одного или нескольких), есть условие на превышение данного порога. При этом я хочу, чтобы во View персонажа выводились статус-иконки типа "готов к усиленным атакам" и "готов к супер-атакам". Как правильнее сделать с т.з. MVC? Мне видится либо вариант реализации в Модели этих статусов, т.е. создаём свойство для Character типа Boolean, чтобы при достижении порогового значения оно менялось с false на true и обратно, а view тогда просто отображает эти статусы, не приходя в сознание. Второй вариант - оставлять Модель как есть, ведь для её функционала ничего добавлять не нужно, а во view дописывать логику, что если такое-то значение свойства превысило такой-то порог (всё есть в Модели), это означает, что нужно пользователю вывести вот такую-то иконку.

И ещё вопрос по технике. У нас главный View создаёт два CharacterView для игрока и противника. А в них -
ещё пачка дочерних компонентов: изменяемые портреты, полоски здоровья, статус-иконки и т.п. Корректно ли будет со стороны CharacterView слушать напрямую модель своего персонажа, или всё-таки все данные от модели через главный View должны идти? И как родительские вью должны взаимодействовать с дочерними? У меня пока был только один уровень, с ним было всё просто: родительский компонент обращается к public методу дочернего и передаёт в него данные для отображения. А если таких уровней 3-4?

1) Модель определяет, что МОЖНО показывать (через модификаторы доступа, то есть просто не дает доступа к тому что видеть не нужно). Вью решает, что из доступного НУЖНО показывать (в этом суть Вью и суть РАЗНЫХ Вью).

2) Если ни на что в Модели эти статусы не влияют, я бы повесил это на Вью. Вполне нормально для Вью иметь логику, сравнивающую какие-то данные из модели и производящую из этого новые данные, если они будут использованы только для отображения. Как пример — допустим в инвентаре ты водишь мышкой по разному оружию и внизу окна выводится сравнение с тем оружием, что у тебя сейчас в руках, типа "+15" или "-23", то есть сильнее или слабее. Ежу понятно, что эти +15 и -23 не хранятся ни в какой модели, на кой они нужны. Это все — повод для гордости данной Вьюхи, что она вот такое умеет, умница. И это на самом деле "КАК", а не "ЧТО", потому что "ЧТО" это просто убойка конкретного меча или пистолета, но ее можно показать "КАК" — в сравнении с убойкой другого оружия. В твоем случае есть "ЧТО" — уровень маны сейчас и другое "ЧТО" — необходимое количество маны. А "КАК" Вью это покажет — её дело. Может что-то замигает, что-то засветится, что-то перестанет светиться (в Скайриме например после использования Крика у персонажа должен "отдохнуть" Голос несколько секунд, и все это время светится индикатор, постепенно уменьшаясь).

3) В такой ситуации вполне допустимо для каждой вьюхи общаться напрямую со своей Моделью. Если Главной Вью тоже надо что-то знать о происходящем, она может тоже подписаться на нужную модель и получать те же данные, что и Вью персонажей.

Огромное спасибо за комментарии. Пошёл дальше экспериментировать.