Неоднозначный MVC: причины и следствия
Уровень материала: 🐥 #middle
Ранее я писал, что прохожу обучение на курсе от Unity Architect. Недавно была тема, посвященная MVC. И упор был сделан не на разбор очередной реализации, а на выяснение причин, почему существует такое разнообразие трактовок. Из этого вытекают и некоторые полезные следствия, о которых не часто рассказывают.
Про разнообразие подходов 🛠 :
Причина такого раздрая — «так исторически сложилось». Когда по принципу «глухого телефона» революционный много десятилетий назад подход дошёл до наших современных дней. Подробнее с этим можно ознакомиться в длинном исследовательском материале из двух частей на Хабре: #1 и #2. Текст объёмный и сложный. Но увлекательный. Для вдумчивого чтения (а иначе смысла нет) стоит заложить на обе статьи где-то 1 час.
А один из примеров реализации в геймдеве я шарил в этом посте.
Следствие 1:
MVC — это изначально история про взаимодействие с пользователем. Т. е. про UI. Соответственно, попытки затащить это в геймплей сделают из MVC не MVC (и даже не обязательно какой-то MVx). Т. к. для удобства использования в геймплее эту штуку приходится адаптировать.
Следствие 2:
Как бы ни был «приготовлен» MVC, кто-то обязательно скажет, что это неправильно. Или это не MVC, а какой-нибудь другой MVx. Это бесконечные бессмысленные споры, стоящие на противоречивых источниках.
Чтобы не маячить красным платком перед «искушённой» публикой, можно отойти от общеизвестного нейминга. Соблюсти идею разделения визуала и бизнес-логики, но назвать это иначе. Особенно легко это делается в геймплее.
Ведь задача — спроектировать всё хорошо, а не сдать экзамен по «эталонному соответствию канонам». Тогда на нападки в виде «но в MVx же...» можно отвечать «а это не MVx».
Следствие 3:
Эталонно View и Controller находятся на одном слое взаимодействия с пользователем. И в современных системах, где нет низкоуровневого кода по непосредственно рендерингу и обработке ввода, контроллер как-таковой не шибко нужен. Поэтому достаточно использовать только Model и View.
В качестве Model можно подготовить специальную прослойку, типа Facade, Adapter или Mediator, которая будет агрегировать внутри всю коммуникацию с необходимыми игровыми моделями и сервисами. Например, нажалась кнопочка, медиатор из WalletModel снял монетки, в StorageModel положил конфетки, а у AdService запросил показ InterstitialAd.
В свою очередь View будет отвечать за всю логику представления (кнопочки, формочки, генерация карточек, анимации прокрутки, заполнение прогресс-баров и пр.) и передачу событий в Mediator.
Связку из View и Mediator я и в своей команде использую уже очень давно — это отлично себя показывает в проектах разных масштабов. На каком-то из стримов K-Syndicate оговаривались, что используют двухуровневый шаблон и связующий слой тоже называют Mediator. Не нашёл, на каком именно, но у них был большой классный стрим по MVx в целом.
upd: поступило полезное дополнение со стримом от K-Syndicate про UI без MVx — там рассматривается Mediator, немножко в другой роли, но это тоже даёт полезный взгляд на проблему игрового UI.
————————————